🚀 go-pugleaf

In article <1311@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:
>I think CL is the WORST thing that could possibly happen to LISP.  In fact, I
>consider it a language different from "true" LISP.  
To me, CL is the first "true" Lisp I have seen! Functions are 1'st class
objects, built-in functions have names that describes what they do, not
idiotic short-hands like Maclisp's munkam or Franz' dtpr, it has the nicest
set of data types I have seen (though I admit that it is more an feature 
than an important part of the language) and powerful arithmetic.

>...
>different options.  I think the only thing they left out was FEXPRs...
You don't want FEXPRs. Use macros.

>It is obviously intended to be a "compilable" language, not an interpreted
>language. By nature it will be very slow; somebody would have to spend quite a
>bit of time and $ to make a "fast" interpreted version (say for a VAX).  ...
Why should anyone spend time and money to make a fast interpreter? It is the
compiled code that should be "fast".

>and NIL from MIT DOES NOT HAVE A GARBAGE COLLECTOR!!!!  It just eventually eats
>up it's entire VAX/VMS virtual memory and dies...
>
Neither have Zetalisp on the Lambda... What's that got to do with the language
definition?

>The entire INTERLISP arena is left out of the range of compatability.
Yes, fortunately!

>As a last shot; most of the fancy Expert Systems (KEE, ART) are implemented in
>Common LISP.  Once again we hear that LISP is "too slow" for such things, when
>a large part of it is the use of Common LISP as opposed to a "faster" form
>(i.e. such as with shallow dynamic binding and simpler LAMBDA variables; they
>should have left the &aux, etc as macros).  Every operation in CL is very
>expensive in terms of CPU...
If so, it is time to build new machines that supports the language better.
For years now we have built the machines and then designed the languages for
them when it should be the other way around. That's why we are stuck with
ugly things like F-N, Pascal and C. (No flames plz, I've heard them before.)

>I forgot to leave out the fact that I do NOT like lexical scoping in LISP; to
>allow both dynamic and lexical makes the performance even worse.  To me,
>lexical scoping was and should be a compiler OPTIMIZATION, not an inherent
>part of the language semantics.  I can accept SCHEME, where you always know
>that it's lexical, but CL could drive you crazy (especially if you were 
>testing/debugging other people's code).
That is perhaps a matter of tast but I do like lexical scoping. I have
tested/debugged a lot of "other peoples" Maclisp and Franzlisp code which is
heavily built on dynamic scope (which is a type of side effect to me) and
*that* can drive you crazy.
Besides, when do you get dynamic scope without asking for it? The only
(few) cases I could find is when it is "natural" (in some way), 
ex. with-open-file.
Lexical scoping *IS* a part of the language semantics! Lexical scoping as
a compiler optimization seems utterly stupid to me.

>BTW, I think the book is poorly written and assume a great deal of knowledge
>about LISP and MACLISP in particular.  I wouldn't give it to ANYBODY to learn
>LISP
>
>...Not only does he assume you know a lot about LISP, he assume you know a LOT
>about half the other existing implementations to boot.
>
It is simply not a tutorial book. It is a book for Lisp hackers/implementors/
developers.

>Friday I was in a bookstore and saw a new LISP book ("Looking at LISP", I
>think, the author's name escapes me).  The author uses SETF instead of SETQ,
>stating that SETF will eventually replace SETQ and SET (!!).   Thinking that
				   ^^^^^^^^^^^^^^^^^^^^
>this was an error, I  checked in Steel; lo and behold, tis true (sort of).
It is an error. SETF will (eventually) replace SETQ. It can not replace SET.

>In 2 2/3 pages devoted to SETF, there is >> 1 << line at the very bottom
>of page 94!  And it isn't even clear; if the variable is lexically bound AND
>dynamically bound, which gets changed (or is it BOTH)?  Who knows?  Where is
>reference?
At the moment of reference you can only see one binding of a variable. Which
one depends of the circumstances and follows the rules outlined in chapter 3.
I have never had any trouble with this, it is very simple.

>"For consistency, it is legal to write (SETF)"; (a) in my book, that should be
>an error, (b) if it's not an error, why isn't there a definition using the
>approprate & keywords?  Consistency?  Generating an "insufficient args"
>error seems more consistent to me...
>
>Care to explain this to a "beginner"?  Not to mention that SETF is a
>MACRO, by definition, which will always take longer to evaluate.
>
All functions and special forms that allow a infinite number of arguments
should allow zero args if possible, for consistency. Care to explain to a
"beginner" why a function that allows one, two, three or X (pair of) 
arguments should not allow zero arguments?
Macros do NOT always take longer to evaluate. It may be true interpreted
but never compiled.

>Then try explaining why SET only affects dynamic bindings (a most glaring
>error, in my opinion).  Again, how many years of training, understanding
>and textbooks are suddenly rendered obsolete?  ...
It is obvious. If SET affects lexical bindings a function may not always
return the same thing depending on the names of its (lexical) variables.
Suppose SET did change lexical bindings and you have this (silly) function :
(defun foo (a b) (set a b))
Now, if you have a variable 'x' dynamicaly bound to 42 then the call
(foo 'x 666)
would, of course, change the dynamic binding of 'x' to 666. But if your
dynamic variable happen to be called 'a' the call
(foo 'a 666)
would NOT change the dynamic binding of 'a' which is probably not what
you expected...


					PEM
-- 
Per-Erik Martin,  Computing Science Dep., Uppsala University, Sweden
UUCP: martin@kuling.UUCP  (...!{seismo,mcvax}!enea!kuling!martin)