From: ·······@well.UUCP
Subject: Against the Tide of Common LISP
Date:
Message-ID: <2624@well.UUCP>
In <····@Shasta.STANFORD.EDU>, Andy Freeman writes:
>I've forgetten why JJ is so down on macros; doesn't "real" lisp have
>them?
I'm not down on macros; I am down on SETF.
In a nutshell, SETF is essentially
a primitive, i.e. there are no corresponding operations for
many of it's features, so, as a macro, it becomes excessively
expensive, particularly for arrays. I also don't believe that 'primitives'
anything other than a fixed number of arguments.
Both of these aspects should be reserved for a "higher level".
Jeffrey M. Jacobs
CONSART Systems Inc.
Technical and Managerial Consultants
P.O. Box 3016, Manhattan Beach, CA 90266
(213)376-3802
CIS:75076,2603
BIX:jeffjacobs
USENET: ·······@well.UUCP
From: ·······@well.UUCP
Subject: Special Variables in Common LISP
Date:
Message-ID: <2625@well.UUCP>
In <···@lmi-angel.UUCP>, Bob Krajewski writes:
>In other words, why would anybody do
> (let ((lose-p nil))
> (save-the-world))
>unless LOSE-P was a special variable which evidently affected the behavior
>of the SAVE-THE-WORLD function ? If the variable LOSE-P were not special,
>the compiler would probably warn about the useless binding.
Let me change the example a little bit; let's make it
(DEFVAR LOSE-P NIL)
(DEFUN NOT_SURE_YET (LOSE-P) (SAVE-THE-WORLD))
Possible reasons for this:
1. NOT_SURE_YET isn't completely defined, yet.
2. It is anticipated that NOT_SURE_YET might, in the future, need to
change the value of LOSE-P.
3. It is a primary function of a package, such as an editor,
with LOSE-P the key global variable. Think of calling a structure
editor with the form to be edited.
Remember that the domain under discussion is that of debugging
*other* people's code, not reading people's code for interest
or fun. If they were writing reasonable code, I wouldn't have
to be debugging it :-)
Jeffrey M. Jacobs
CONSART Systems Inc.
Technical and Managerial Consultants
P.O. Box 3016, Manhattan Beach, CA 90266
(213)376-3802
CIS:75076,2603
BIX:jeffjacobs
USENET: ·······@well.UUCP
From: ·······@well.UUCP
Subject: Against the TIde of Common LISP
Date:
Message-ID: <2626@well.UUCP>
In <·······@hpfclp.HP.COM>, Chan Benson writes:
>>B.S! All the compiled code for SET need do is check that the first argument
>>be lexically equivalent to a lexically apparent variable and change
>>the appropriate cell, stack location, or whatever. Easy for a compiler
>>to do!
>I don't see how it's possible to do this (excuse my potential ignorance).
Let's take a simple example:
(DEFUN FOO (X Y Z) (SET X (CONS Y Z)))
The compiler would have to generate code that would effectively
be equal to
(COND ((EQ X 'X) (SETQ X (CONS Y Z)))
((EQ X 'Y) (SETQ Y (CONS Y Z)))
((EQ X 'Z) (SETQ Z (CONS Y Z)))
(T (SET-SYMBOL-VALUE X (CONS Y Z)))))
i.e. a hidden 'macro-expansion' at compile time. This should put
to rest assertions that it "can't be done"; it's actually trivial.
(Whether it's desireable or not is another discussion).
Jeffrey M. Jacobs
CONSART Systems Inc.
Technical and Managerial Consultants
P.O. Box 3016, Manhattan Beach, CA 90266
(213)376-3802
CIS:75076,2603
BIX:jeffjacobs
USENET: ·······@well.UUCP
From: ······@mit-eddie.UUCP
Subject: Re: Against the TIde of Common LISP
Date:
Message-ID: <4934@mit-eddie.MIT.EDU>
In article <····@well.UUCP> ·······@well.UUCP (Jeffrey Jacobs) writes:
Describing a way for SET to assign to lexical variables:
>(DEFUN FOO (X Y Z) (SET X (CONS Y Z)))
>
>The compiler would have to generate code that would effectively
>be equal to
>
>(COND ((EQ X 'X) (SETQ X (CONS Y Z)))
> ((EQ X 'Y) (SETQ Y (CONS Y Z)))
> ((EQ X 'Z) (SETQ Z (CONS Y Z)))
> (T (SET-SYMBOL-VALUE X (CONS Y Z)))))
That is the wrong thing, though. Consider FOO being used in the
following:
(DEFUN FOO-CALLER (ARG1 ARG2)
(LET ((X 3))
(FOO 'X ARG1 ARG2)
(PRINT X)))
The X that is passed to FOO is in the lexical scope of FOO-CALLER, so
it is the one that one would expect to be assigned. One of the goals
of lexical scoping is that it should not make any difference to the
caller what the names of locals are in a function; if a lexical
variable is renamed, the only places you have to look for references
to the variable is within the lexical scope of that variable. The
parameters to FOO are not lexical variables because they can be
referenced outside the function.
I will admit that there are uses for this type of thing; for example,
in an object-oriented programming system implemented using lexical
variables, one might have a SET-INSTANCE-VARIABLE function that takes
the name of an instance variable. However, this would probably differ
from FOO because it wouldn't have the T clause, since it is ONLY
interested in lexical variables. I doubt that there is a use for the
generality of the FOO example, in which SET will set either a lexical
or special.
--
Barry Margolin
ARPA: ······@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar
From: ·······@well.UUCP
Subject: Common LISP Scoping and Variables
Date:
Message-ID: <2627@well.UUCP>
In <····@mmm.UUCP>, Bill Rouner writes, asking for help in
debugging:
>(defun foo ()
> (let ((a '(this value set in the let)))
> (eval (car '(a)))))
Page 321 actually provides a nice, coherent explanation, "the
form is evaluated in the *current* dynamic environment and
a *null* lexical environment.
Aren't the new scoping rules fun? (Disclaimer: I don't know
Bill Rouner, and his msg was not set up to support any of
my claims about Common LISP.
Will Clinger, in <····@tekchips.TEK.COM>, writes a very nice
explanation of the problem, but then goes onto confuse things
with a SCHEMEr's viewpoint of the world (valid but different). To
wit:
>By the way, lists are not expressions either. The general principle
>is that data structures and code are entirely disjoint. Apologists
>for Lisp have historically done their best to say that data structures
>and code are the same, and Common Lisp retains some really bizarre
>things to make that seem so, thus the confusion continues.
One of the key issues that I consider distinguishes "Real LISP" from
Common LISP is indeed the strong committment to the equivalence of
data (meaning list structures) and code. I consider this
idea one of the foundations of "Real LISP", and Common LISP intent
is vague at best. InterLISP, for example,
still makes a declaration of this philosophy in the manual, and it is still one
of the keystones in the teaching of LISP (although whether it
should be when teaching Common LISP is open to question).
SCHEME does not share this philosophy.
Will is correct in asserting that Common LISP does do some very
bizarre things to try and keep this; the lack of a syntactical distinction
between variables and symbols is absurd, as Bill's example points
out.
Note that there is a difference between "code and data being
equivalent, i.e. list structures" and "code being data, i.e. functional
objects".
If variables and symbols are to be truly disjoint,
then there should be a *syntactic* distinction.
If code and data are to be truly disjoint (non-equivalent), then
Common LISP's syntax becomes a real loser; there's no good reason
not to support better syntactic constructs, and not much reason
to inflict Lots of Insidiously Stack Parends on the world!
Jeffrey M. Jacobs
CONSART Systems Inc.
Technical and Managerial Consultants
P.O. Box 3016, Manhattan Beach, CA 90266
(213)376-3802
CIS:75076,2603
BIX:jeffjacobs
USENET: ·······@well.UUCP
From: ···@spice.cs.cmu.edu.UUCP
Subject: Re: Against the Tide of Common LISP
Date:
Message-ID: <1144@spice.cs.cmu.edu>
I found this highly relevant document about the Common Lisp design process
while cleaning my directory. It was written by Skef Wholey, who implemented
a large part of Spice Lisp while a full-time undergraduate student. The
Common Lisp spec was being developed at the same time that Spice Lisp was
being written. This was a cause for no little aggravation for Skef, since he
often had to rewrite code several times.
________________________________________________
Common LISP
(to the tune of Dylan's "Maggie's Farm")
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
See, it was spawned from MACLISP,
And then they threw in Scheme,
And now everybody's made it
"just a little" short of clean.
The language specification is insane.
I ain't gonna hack on Guy Steele's LISP no more,
I ain't gonna hack on Guy Steele's LISP no more.
When you mail him a question,
And then wait for a reply,
Well you can sit for weeks now,
And begin to think he's died.
His MAIL.TXT is one great big black hole.
I ain't gonna hack on Fahlman's LISP no more,
I ain't gonna hack on Fahlman's LISP no more.
Well he gives you an X-1,
And he puts you on a Perq,
And he asks you with a grin,
"Hey son, how much can you work?"
If I reboot one more time I'll lose my brain.
I ain't gonna hack on Dave Moon's LISP no more,
I ain't gonna hack on Dave Moon's LISP no more.
We had a simple SETF,
But it choked on LDB.
So Lunar Dave done fixed it:
Go look at page eighty three.
The Gang of Five they didn't take a poll.
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
With its tons of sequence functions,
And its lexical scoping,
I've now begun to like it,
But the users are moping:
"Without EXPLODE my life is full of pain."
(harmonica and fade)