26 february 1992
Subject: Stop technical detail discussions,
Start Power Of Lisp Competition.
Apart from simple questions from lisp novices, most of the
discussions in this lisp newsgroup seem to be
theoretical rear-guard disputes about technical details
in the Common lisp and CLOS standards.
Subjects from the latter group are e.g.
- the variety of parameter passing in functions,
- the pro's and con's of the package system,
- should eval be used in programs, etc.
Most articles opposing against something (such as something
should not be in the standard, or that some destructive function
has indeed side-effects and "it shouldn't") are written by
persons having
1. a strong personal taste and want to force it to others
2. a very limited knowledge of lisp
3 a very limited insight of what lisp can be used for
4. more a grumbling mind than a sparkling mind.
Of course I know that I'm grumbling right now, but recursion
should be familiar to lispers.
This all is bad for the language we love. IT IS BETTER TO SHOW
TO EACH OTHER THE POWER OF LISP. Therefore I propose to start
the Power Of Lisp Competition (POLC).
The one who has send in the most powerful function per line
(w.r.t. functionality and speed divided by its size)
gets the Golden Parenthesis Award.
The rules are as follows:
1. Only use Cltl1&2 standard.
2. The function should solve a well-defined problem,
but the problem need not be a real-world problem.
3. The function should not exceed 20 lines of code,
the shorter the better. Comment doesn't count.
Very long lines make a bad impression.
4. The documentation must clearly state what is solved.
5. POLC functions must be send in via the comp.lang.lisp newsgroup.
6. Bugs disable competition.
7. The determining factor for winning the award is the
formula (/ (* functionality efficiency) size).
The first selection for the Golden Parenthesis Award will
be made from the POLC functions send in untill 31th of March '92.
Depending on the reaction, it will be repeated afterwards.
People who want to join the POLC committee,
please do by mailing me directly.
Below, you find the first POLC example.
Ton Kostelijk,
Philips Research Lab Eindhoven,
the Netherlands,
email: ········@prl.philips.nl
;
;
; TRANSPOSE (m)
; m: matrix, format: ( (<number>* ) *)
; sublists of m should be of equal length.
; result: transpose of m
;
(defun TRANSPOSE (m)
(if m (apply #'mapcar (cons #'list m))))
;
;
In article <····@prles2.prl.philips.nl> ········@rabban.prl.philips.nl (T. Kostelijk 43897) writes:
From: ········@rabban.prl.philips.nl (T. Kostelijk 43897)
Newsgroups: comp.lang.lisp
Date: 26 Feb 92 14:39:50 GMT
Apart from simple questions from lisp novices, most of the
discussions in this lisp newsgroup seem to be
theoretical rear-guard disputes about technical details
in the Common lisp and CLOS standards.
Subjects from the latter group are e.g.
- the variety of parameter passing in functions,
- the pro's and con's of the package system,
- should eval be used in programs, etc.
I guess I disagree with this characterization. Often "simple" questions
lead to discussions of how to think about a given feature. The questions
of the relation of packages to CLOS brought up issues, that to my
simple mind still aren't totally settled. Questions of eql specialization,
(ie. the "right" cases) are bandied about, but I feel I am still not
totally settled about this either. Until one of my coworkers showed
me a totally cool example of the use of symbol-macrolet, I really hadn't
considered it part of my standard set of things to do with lisp.
I also don't mind folks talking about language design issues. It is
interesting to know the discussions around various X3J13 actions.
Yes some of it is personal opinion, and maybe it gets out of hand
sometimes (that's what the d key is for), but I for one like to know
what the issues are.
Finally, I disagree with the idea that you can show the power of
lisp in small bits of code. You can show programming elegance (maybe)
or even a cool idea. To see the power of say, keywords, and rational
use of data structures I would submit that a person should try using
the C interface to Xlib, versus using CLX. (having personally done
both). Looking at how these both are structured you can partially
see the abstraction, and programming support that lisp brings.
(eg. Xlib calls have, I dunno, typically 9000 arguments. With keywords,
reading the code is MUCH easier. There are other more subtle things).
Mark.
In article <····@prles2.prl.philips.nl> ········@rabban.prl.philips.nl (T. Kostelijk 43897) writes:
>The rules are as follows:
...
I notice that there was no "originality" rule. Is there any prohibition
against submitting derivatives of other posters' submissions?
> 7. The determining factor for winning the award is the
> formula (/ (* functionality efficiency) size).
>(defun TRANSPOSE (m)
> (if m (apply #'mapcar (cons #'list m))))
Here's my submission, which should narrowly beat the above:
(defun transpose (m)
(if m (apply #'mapcar #'list m)))
It does one less CONS, so it should be more efficient; Mr. Kostelijk was
apparently using the less powerful APPLY of older Lisp dialects, instead of
the Common Lisp version that allows any number of arguments before the list
argument.
After all this, I agree with the other poster who said that this is a silly
competition. Lisp's power is in its ability to solve *big* problems. For
instance, small programs in languages with manual storage management don't
generally suffer from dangling pointer problems; you only really need
automatic storage management when you have large programs with dynamic
reference relationships between data structures.
Yes, Lisp's large library of built-in functions is important, but it's not
the distinguishing feature of the Lisp family of languages (many members of
which don't have such a large library).
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
How about numerical integration of multiple, definite integrals?
Take your favorite integration method with an interface such as
(integrate epsilon from to proc)
First-class procedures enable one to integrate over an arbitarary
number of axes, e.g.,
(integrate 0.01 0 1
(lambda (x)
(integrate 0.01 0 1
(lambda (y)
(+ (* x x) (* y y))))))
without having to define a special integration procedure for each
number of integration levels. Try doing that in Fortran.
John Baugh
···@cepmax.ncsu.edu
In article <····@prles2.prl.philips.nl> ········@rabban.prl.philips.nl (T. Kostelijk 43897) writes:
Subject: Stop technical detail discussions,
Start Power Of Lisp Competition.
This all is bad for the language we love. IT IS BETTER TO SHOW
TO EACH OTHER THE POWER OF LISP. Therefore I propose to start
the Power Of Lisp Competition (POLC).
The one who has send in the most powerful function per line
(w.r.t. functionality and speed divided by its size)
gets the Golden Parenthesis Award.
Fun!
; TRANSPOSE (m)
; m: matrix, format: ( (<number>* ) *)
; sublists of m should be of equal length.
; result: transpose of m
;
(defun TRANSPOSE (m)
(if m (apply #'mapcar (cons #'list m))))
Isn't (when m (apply #'mapcar #'list m)) more compact and clear?
My contribution to the Power Of Lisp Competition:
; FIBONACCI (n)
; m: positive integer
; result: fibonacci of n in log(n) time (do I have to prove it?)
; The function relies heavily upon Lisps multiple-values and generic
; math. I would never have written it in an other language. And it is
; fast enough.
(defun FIBONACCI (n)
(flet ((fib-aux (n f1 f2)
(cond ((< n 2) (values 1))
((evenp n) (+ (* f1 f1) (* f2 f2)))
(t (* f1 (+ f1 (* 2 f2)))))
))
(case n
((0 1) (values 1 n 0))
(2 (values 2 1 1))
(t (multiple-value-bind (f1 f2 f3) (FIBONACCI (truncate n 2))
(values (fib-aux n f1 f2)
(if (evenp n)
(fib-aux (1- n) f2 f3)
(fib-aux (1- n) f1 f2))
(fib-aux (- n 2) f2 f3))
)))
))
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 2 45 20 10
Fax: +47 2 45 20 40
Email: ········@si.no
--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY
Tlf: +47 2 45 20 10
Fax: +47 2 45 20 40
Email: ········@si.no
In article <····@prles2.prl.philips.nl>, T. Kostelijk 43897 writes:
> Subject: Stop technical detail discussions,
> Start Power Of Lisp Competition.
> ...
> The rules are as follows: ...
> 6. Bugs disable competition.
> ;
> ; TRANSPOSE (m)
> ; m: matrix, format: ( (<number>* ) *)
> ; sublists of m should be of equal length.
> ; result: transpose of m
> ;
> (defun TRANSPOSE (m)
> (if m (apply #'mapcar (cons #'list m))))
I'm nitpicking, of course, but this entry must be disqualified.
The number of `rows' (and cols, too, actually) must be less than
call-arguments-limit.
Since it's not mentioned in the documentation, it must be a bug.
Or is it a feature? :>
And, I'd say that comment lines that describe _limitations_ of the
algorithm should count against the `lines of code'!
In any case, I'd have to agree with other posters that this really does
not show the power of lisp. It may be a bit fun (or not).
The way to use this sort of game to make any language A look better than
language B is to find a built in function, or library function or
whatever, that exists in A but not in B.
Then the A implimentation is simply
(foo this that).
The code in B has to be explicit. Obviously it's functionality/code-line
is poor. QED.
Perhaps the whole thing was intended to be taken a bit tongue-in-cheek,
but you didn't specify how "functionality" was measured.
It's on the scale of `real programs' that do `real work' that the
differences are more meaningful. Expressiveness & readability come
heavily into play. But a `real program' is seldom readable enough that
we want to read dozens of them on the net to prove to ourselves what we
already know: Lisp is better. :>
Someone compared X & CLX; I've never programmed in either, but I've
`read' some C code for X. My only thought was "I've seen this program
run, so this code _must_ mean something."
In article <····@prles2.prl.philips.nl>, T. Kostelijk 43897 writes:
> Subject: Stop technical detail discussions,
> Start Power Of Lisp Competition.
[...]
I agree with Barry, et al, that "power per line of code" for small
programs doesn't prove much about the language. *BUT*, I don't want
to discourage people from posting neat hacks, as this is invariably
fun (and sometimes even useful)...
- Marty
(setf (need-p 'disclaimer) NIL)
In article <····@prles2.prl.philips.nl> ········@rabban.prl.philips.nl (T. Kostelijk 43897) writes:
> The one who has send in the most powerful function per line
> (w.r.t. functionality and speed divided by its size)
> gets the Golden Parenthesis Award.
Here's my entry:
;;; A no-frills Lisp interpreter
(defun read-eval-print-loop ()
(loop (print 'lisp>) (prin1 (eval (read)))))
(Well, *someone* had to say it.)
-- rar