🚀 go-pugleaf

In <3827@utah-cs.UUCP>, Stanley Shebs responds to
my original article, <1311@well.UUCP> jjacobs@well.UUCP...

 >I don't why I'm bothering to respond to this uninformed flame, but I've got
>a few minutes to kill before running off to the compiler conference...
>Besides, somebody might read this and suppose that this Jeff Jacobs
>knows what he's talking about, which is rarely the case, based on this
>limited sample.

>I think those who flame about language designs should be forced to
>design, implement, and distribute their own language, then listen
>while know-nothing second-guessers complain about things they
>don't understand to begin with...

I certainly appreciate personal attacks like this; they make things so much
livelier :-).  To make my ignorance perfectly clear, let me state that I have
not only been extensively involved in design and distribution of LISP (and
other sytems); my experience started in 1971 with UCI LISP.  You can find
my name along with the other people who really did the work on the front
page of the Meehan book.  BTW, James Meehan had nothing to do with the
original implementations; all he did was edit the book (mostly just reproducing
the manuals; he didn't even do much editing).  "The New UCI LISP Manual"...

It's a bad idea to jump to conclusions about other people's ignorance based on
a limited sample, particularly in this medium.  (Ad hominem attacks are also
considered bad form).

>Well gee, I wonder what is "true" Lisp...

Let me use the term "Real LISP" (RL) instead.  I am not going to give a 
definition that will be worth flaming at.  The point is that CL makes a
_radical_ departure from previous LISP work both in terms of syntax
and semantics.  As an oversimplified definition; development environment
is interpreted with dynamic scoping (lexical scoping is a compiler
optimization), no distinction between executed code and data unless 
specifically compiled (i.e. not incrementally compiled),
no required keywords and pre-CL function definitions (such as MEMBER).
Examples include MACLISP, INTERLISP, FRANZ and UCI.

>>  CL has everything in the
>>world in it, usually in 3 different forms and 4 different flavors, with 6
>>different options.

>Actually, they decided to omit flavors, because no one could agree on
>a standard! :-)

>>  I think the only thing they left out was FEXPRs...

My error here; FEXPRs are easily duplicated. What is really left out is
MACROs, i.e. access to the actual form.

>FEXPRs are bad (see Pitman's paper in the 1980 Lisp conference)

How did all that work get done before 1980?  If we'd only known we were doing
it wrong :-).  Because of the above, I won't bother to address the Pittman
paper.

>>It is obviously intended to be a "compilable" language, not an interpreted
>>language.

"Compilable" should read "compiled"...

>Can't beat the speed of C programs by running interpreted, you know...

But you can get one heck of a better development environment running 
interpreted...

>>it was several years before Golden Hill had lexical scoping,
>>and NIL from MIT DOES NOT HAVE A GARBAGE COLLECTOR!!!!

>So what do broken implementations have to do with the language standard?

It's not a matter of "broken", it's a matter of incomplete.  How much time, 
effort and money will it take before a "complete" implementation that doesn't 
derive from SPICE will appear?

>Many of the vaguenesses in the Common Lisp standard are to allow
>implementations some freedom to do things in different ways  Would
>you like it if the *language* standard said that the architecture will
>be tagged, and that positive fixnums range between 0 and 32767, and
>that they will have a tag of 42?

Much of the vagueness will have a direct impact on the user and the
portability of code.

>Most folks that haven't followed the Common Lisp effort don't realize
>how monumental a task it was to get all the Maclispers to agree on a 
>language standard.  There is simply no way to get a Lisp that is both
>Maclisp- and Interlisp-compatible.

Seems easy enough to me; just put everybody's favorite feature into the
language and you can get agreement :-).

I do like the casual way Interlisp is just ignored; nothing of any importance
has ever been done in Interlisp anyway :-).

Being serious, your statement is ridiculous.  CL isn't Maclisp compatible 
either. There is a great range of commonality between Interlisp and
Mac-lispish implementations.  (We stole from the best for UCI LISP <grin>).
But there is also a tremendous rivalry between the 2 camps, and a tremendous
financial investment in Interlisp...

>>I forgot to leave out the fact that I do NOT like lexical scoping in LISP;

>I LIKE lexical scoping in Lisp - dynamic scoping is for special situations,
>like rebinding a global variable for the duration of a function (for
>instance, one gets an equivalent effect to Unix redirection by rebinding
>*standard-input* or *standard-output* to file streams).  There is no
>good way to do this if you don't have dynamic scoping.  Programs that
>rely heavily on dynamic scoping are usually sloppily written and extremely
>difficult to analyze - things go on behind your back all the time.

Thanks for your tutorial, I had NO idea what it was for:-).  

>Default dynamic scoping in Lisp is the result of history - in 1958,
>programming language semantics was not well understood!  In another
>20 years, no one will understand why anyone would suggest that default
>dynamic scoping was a good thing.

We are actually fairly close on this issue!  I certainly would not design a
_new_ language with dynamic scoping as the default.  (One of the reasons I
state that CL is a NEW language, different from RL).

The main reasons I suggest dynamic is preferable in LISP are a) historical, 
b) LISP is not block structured; the separation of declaring a variable 
SPECIAL (DEFVAR being recommmend, p 68) from an actual function definition 
makes it very difficult to debug a function "locally", 
c) the excessive need to provide compiler declarations makes for some pretty 
ugly code.

Well written LISP code should be almost completely independent of lexical or
dynamic scoping considerations.  A free variable is obviously special; the
only real problem comes in when a variable is bound.

>>to allow both dynamic and lexical makes the performance even worse.

>This is totally wrong.

Say WHAT?  It certainly is TRUE in an intepreter; it takes longer to look up
a lexical variable than a dynamic variable, and it takes even longer when you
have to determine whether the lookup should be lexical or dynamic.  Add a
little more time to check if it's a CONSTANT or DEFVAR...

>To put things in perspective, the Zetalisp language (that the Symbolics
>people sell like hotcakes for big bucks) is at least an order of magnitude
>larger and more complex than Common Lisp, which they consider to be a small
>subset for the exchange of programs.  All reports have been that the
>Symbolics is super-fast for development and for execution... does anyone
>want to contradict me?

To put things even more in perspective, Symbolics do not "sell like hotcakes".
I don't have the number handy, but I believe the number of units sold is less 
than 4000.  Big bucks is putting it mildly; figure a minimum of $120,000 for a 
decent, single user system.  Zeta-Lisp is bigger, but not in the same way as
CL; the "biggness" is in the environment and number of available functions 
(ala INTERLISP).  And it REQUIRES very expensive, very specialized hardware.
And nobody  runs in CL mode by choice; it slows things down a LOT
(and still isn't complete).

If you would like to assert that the only way to get a decent CL
implementation  is to develop a Symbolics class machine for it, I'll be glad
to agree :-).

But I'm real tired of hearing that LISP "is slow" and requires special
hardware ; if you can't work with gp multi-user hardware, maybe you should be
doing something else.

BTW, I've heard reports that Le-LISP can give Symbolics a run for the money
using gp architectures.

>Neither would I - it's not *supposed* to be an instructional book.

So what is everybody supposed to have learned from?

>There are some problems, which is why
>there is another version in the works.  Almost all of the problems are
>extremely technical, and take a long time just to explain to someone not
>familiar with the language, let alone to solve...  There are also some open
problems with language design involved - like compiling to different machines
within the same programming environment, and support of program-analyzing
programs in a portable manner.

No sh*t, Sherlock!  You think the flames I've put up are even half?

Do you think maybe the drive to make it a "standard" may be just a wee bit
premature?

>>There is nowhere near the basic underlying set of primitives (or
>>philosophy) to start with, as there is in Real LISP (RL vs CL).

>Finally, a semi-valid point.  There has been some effort to define various
>subsets, but no consensus has emerged.  Any time someone defines a subset,
>everybody whose favorite feature has been left out will rant and rave and
>insist that it be included.  By the time you're done, you've got the whole
>language again (spoken from personal experience!).

The point isn't the lack of a subset, it the lack of a starting set.  RLs 
started with a small basic set of types and functions.  Even though they
grew to tremendous size, the growth was mostly by adding new functions.
CL starts out with a tremendous base language, attempting to have everything
in it.  The user pays the price for this...

This also goes along with my earlier explanation about how agreement was
reached among the LISP community.  You have my sympathies.  It was a lot
easier in my in the "good ol" days...

>As for the non-use of Lisp definitions, most such definitions are either
>simple and wrong, or complicated and right.

That is almost slanderous; do you really want to stand there and say that
about all the other LISP manuals around?  I find it a lot easier to 
understand a well defined function than prose.
I always find that I get scr**ed by the sentence I didn't read.  Good
readers tend to skim.

>Chapters 3 and 5 contain information about scoping and binding rules.
>Guy Steele has mercifully not repeated the obvious throughout the book!
>To answer your question, (SETF x y) *always* expands into (SETQ x y);
>see the top of page 94.  SETQ sets the lexical binding if there is one,
>otherwise the dynamic binding; see the definition of SETQ on page 91 
>(where there is a reference to the "usual rules"), and the definition
>of "usual rules" in the section on variables, p. 55.  I think it would
>be impossible to write a language standard that caters to those who
>can't read.

Thanks for the references.  Too bad there aren't any in the book....

Unfortunately this isn't written in the proper style of a standard, and I
don't think I should have to read 5 pages to find what should be clearly 
and simply stated under the function definition.
Take a look at IEEE and ANSI standards to see what a "real" standard should
look like.  If I look up SETF, I should be able to
find out what it does, not have to read back to the chapter preface.

As you so clearly point out, it's a lousy reference manual to boot!

>>Then try explaining why SET only affects dynamic bindings (a most glaring
>>error, in my opinion).

>So how in the world are you going to get this to work in a compiler that
>compiles lexical references into positions on stack frames?

That's the implementor's problem <grin>. It can be done (but probably
isn't worth it).   See below for how this should have been handled.

>>  How many books say
>>(SETQ X Y) is a convenient form of (SET (QUOTE X) Y)?  Probably all
>>but two...

I will agree that the _definition_ of SET given  is definitely useful; what I
object to is the capricious changing of the semantics of a function that
is so old and so ingrained in RL.  It SHOULD HAVE BEEN GIVEN A NEW NAME!!!!!!!
(And this applies to every other function whose historical RL definition has
been incompatibly changed).

CL is supposed to promote compabitility etc.; the first thing it does is
become incompatible with most other LISPs.

>I use my Lisp 1.5 manual for historical research only (sorry JMC).

Maybe you should do a little more historical research!  Or at least read
something besides Steele and Winston&Horn v2.

>>  Again, how many years of training, understanding and textbooks are
rendered obsolete?

>Those folks that managed to pass CS 101 shouldn't have any problem.

Passed CS 101 at what school?  What year?  Using what implementation of LISP?
If you spend 10 years using SETQ thing it's the same as (SET (QUOTE)...
or MEMBER is different from MEMQ, and suddenly it all changes, you're
gonna be damned unhappy.  Especially if you have trained other people and
your company's business depends on getting debugged software out the door.
(Or, in my case, you often make a living debugging other people's code).

>MEMQ is a stupid name.

So is SHEBS, (the best I can do for an ad hominem argument :-) .

But it's obviously distinct from MEMBER, and has a great deal of "historical"
weight behind it...

>>MEMBER isn't the only case...

>This was a tough problem for the designers.  On the one hand, everybody
>complains about non-obvious names like CAR and CDR and MEMQ.  On the
>other hand, the considerably better name MEMBER, which ought to be used
>to denote *all* sorts of membership tests, had been grabbed up for EQUAL
>tests.  I would rather have one obvious function name than MEMBER, MEMQ,
>MEMQL, MEMBER-EQUALP, ad nauseam.  And I *especially* don't want to
>write my own membership tests just because I needed to use some specialized
>test function!!

Fine.  I don't agree, but DON'T CALL IT MEMBER!!  Call it something else and
if you want to add funky syntax and make it a special form, be my guest.  But
don't kill my working code that goes back many years!!!!  And don't
invalidate all of the text books, articles, etc that have already been
written and used for many years!

>I think those who flame about language designs should be forced to
>design, implement, and distribute their own language, then listen
>while know-nothing second-guessers complain about things they
>don't understand to begin with...

Terribly sorry I wasn't available to help with the CL definition.  On the other
hand, perhaps a little more time should have been taken, and some people who
weren't completely devoted to a life of developing LISP per se should also
have been consulted.  Let's face it; design by committee is a polite term.  
The kitchen sink approach is probably more apt.  As you and I point out,
one of the key means of getting agreement was including everybody's favorite
feature!  This ain't "design"...

There are a lot of good things in CL, but it's a mammoth compromise and you
and I both know it.  There are tons of problems and the mad rush to make it
a standard is very premature.   It's the rush to make it a standard that I
object to.  It is simply not a good standard.  As you say:

>Perhaps you should try a non-broken Common Lisp then...
>Not in clever implementations...

Where are these  clever, non-broken Common LISPs?  As I also point out,
implementation is very costly and the results are forcing many firms to
recreate LISP in C to get decent performance for their ES shells.  The only
"non-broken" versions I am aware of are re-written SPICE!  It's hard to
believe that MIT can't come up with a version (or if they have,
they haven't notified me of  the update; last version I have is 0.286).

Perhaps you can keep the personal attacks to a minimum next time.  You may
not know who I am; that doesn't make me an illiterate idiot!  I've probably
been around a LOT longer than you have, and probably have a much wider range
of experience, which is not confined to LISP language development (although we
have more LISP designs than you'll ever see).

-JJ, CONSART Systems Inc.
CIS: 75076,2603
BIX: jeffjacobs