🚀 go-pugleaf

In article <1316@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:
>
>In <3827@utah-cs.UUCP>, Stanley Shebs responds to
>my original article, <1311@well.UUCP> jjacobs@well.UUCP...
>

>>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.

I suppose at this point it's appropriate for me to put on my know-nothing
hat and proceed to comment on the design (or lack thereof) of UCI Lisp.
There's a manual right here... 

>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.

Well in that case, let me substitute the term "Obsolete Lisp".  People
take a dimmer view of poorly defined semantics nowadays - it's no longer
OK for Lisp to be "Fortran with parentheses".

>>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...

Sure - I use the interpreter too.  But WHO CARES about the *performance*
of the interpreter!!!

>>Many of the vaguenesses in the Common Lisp standard are to allow
>>implementations some freedom to do things in different ways
>
>Much of the vagueness will have a direct impact on the user and the
>portability of code.

Yeah, like improve portability, at least when programmers adhere to
the definition of the language.  Are you suggesting the language standard
for the interchange of programs should read like the UCI manual and say that
577777Q represents zero?  I don't think that non-DEC-20 people would
like that part of the specification very much!

>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>).

Somehow I doubt a UCI Lisp program using the ";" or ";;" functions is going to
work very well in Maclisp.  Square brackets in UCI Lisp and Franz won't
go over real well in PSL, where they denote vectors.  UCI Lisp and PSL are
the only dialects to define functions with a macro DE, while Maclisp and
Franz use defun, and Interlispers do it in several different ways.

CL is just as compatible with older dialects as the older dialects are with
each other!  But once you convert to the standard, you don't have to do it
any more...  It's very misleading to suggest that there isn't a lot of pain
and agony to translate one dialect of "Real Lisp" to another.  Tim Finin
wrote his Franzlator to convert Interlisp code to Franz, and it had hundreds
of conversion rules.

Common Lisp has the advantage that a number of experienced Lisp implementors
met and argued about most aspects of the language, while some of the features
of older dialects look like they were put together by an undergrad that had
been dropped on the head as a child.  PSL has this function DELATQIP for
instance, which does destructive deletions on alists using a key, while UCI
Lisp has a function SPEAK which returns the number of CONSes executed
(although it is not said whether this count is reset between GCs - a rather
glaring screwup).  Franz defines (and documents!) operations for beating
on allocated number cells directly, so one can globally change 3.1416 to
be 2.72 (sort of like the undocumented feature of certain Fortrans).

>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.

Huh?  Declaration for what?  Local variables?

>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.

(let ((num 45))
  (mapcar #'(lambda (x) (+ x num)) '(3 4 5)))

I would prefer num to be lexical and not dynamic, even though it is free
within the inner lambda.  It's also not desirable for typos to suddenly
materialize as specials - it would be a tough debug to find.

>>>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...

Ah, we're talking about the interpreter again.  I still don't understand why
anyone would think interpreter performance would matter - the overhead
is so tremendous already that dynamic/lexical lookups aren't necessarily
significant.

>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.

I don't use Lisp machines, I expect my (compiled) Common Lisp programs to
go faster than equivalent C programs, and I beat on the compiler if they
don't go fast enough.

>>Neither would I - it's not *supposed* to be an instructional book.
>
>So what is everybody supposed to have learned from?

Rodney Brooks has a book "Programming in Common Lisp", Bob Kessler is
working on a book that features objects and Common Lisp, and of course
the 2nd edition of Winston & Van Horn's "LISP" uses Common Lisp.

>>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?

These problems certainly aren't solved in UCI Lisp either!

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

So when is it going to be less premature?  When we have 40 mutually
incompatible Lisp dialects instead of only 10?

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

It's definitely an exaggeration to suggest that UCI Lisp has some basic
underlying set of primitives that CL doesn't.

>>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.

Interlisp grew by adding magic flags to every property list in sight.

>CL starts out with a tremendous base language, attempting to have everything
>in it.  The user pays the price for this...

Tremendousness is in the eye of the beholder.  A lot of people want to
make Common Lisp even bigger.  The other aspect (which I mentioned originally)
is that one wants to standardize on user functions, rather end up in a
situation where each site has massive and mutually incompatible libraries,
which defeats portability.  For instance, the UCI Lisp sort function
lexorder is quite different from PSL's gsort.  UCI Lisp's set intersection
function takes any number of arguments, while PSL's only allows 2.
The user pays the price, in porting effort.

>>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.

I was exaggerating perhaps, but it does happen.  Definitions in manuals
are "wrong" if they differ from the source code, which might have error
checks or other argument processing.  For instance, the UCI Lisp manual
has a definition of EQUAL that doesn't say anything about what happens
when comparing arrays, although I might guess that it returns nil.
Without a copy of source code, I can't really be sure.
Sure, you can explain member and some other list
functions by definition, but that's about it.  For instance, (push x place)
sort of expands into (setf place (cons x place)), except that place will
get evaluated twice, so the real macro has to be trickier.  UCI Lisp
avoids this by only allowing variables as places to push things, which
is a nuisance.  I also notice that the UCI manual doesn't have definitions
for any of the array functions, or string functions, or explode, or
many others.

>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.

SETF contains a fine description of what it does.  It is clearly unreasonable
to expect that the description of SETF should also include documentation
on SET, RPLACA, and everything else that it expands into, or tutorial
material on the handling of symbols and their values.

A "real" standard (there's that word "real" again!), for instance my copy
of the Ada standard, has *hundreds* of cross references.  You can bet that
when Common Lisp becomes an ANSI standard, its document will be just the
same.

>>>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.

Presumably UCI Lisp does it wrong too, since the manual notes (p. 105) that
"In compiled functions, SET can be used only on globally bound and
SPECIAL variables".  Should I assume that this gross difference in
the behavior of compiled and interpreted code is another "optimization"?

>>Those folks that managed to pass CS 101 shouldn't have any problem
> [with different languages]
>
>Passed CS 101 at what school?  What year?  Using what implementation of LISP?

We try to teach our students enduring principles while encouraging them
to be flexible in the minutiae of languages and programs.

>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.

That's life in Lisp land.  Personally, I welcomed most of the changes in
Common Lisp, since they were considerable improvements over the bizarrities
of other dialects, which I had been annoyed at for a long time.

>>MEMQ is a stupid name.
>
>So is SHEBS, (the best I can do for an ad hominem argument :-) .

Maybe you should put a SHEBS function in UCI Lisp then - it takes any
amount of arguments and returns a random flame!

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

"Historical weight" - spare me!  This isn't Fortran or Cobol, whose
definitions haven't changed significantly in almost the entire history of
computer science!

>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.

Ah, but if we call it DIFFERENT-MEMBER-WITH-JJ-APPROVED-NAME, then many
people will complain because the name is too long, or because it's different
from MEMBER, or any number of other reasons.

>But don't kill my working code that goes back many years!!!!

Nobody's forcing you to use Common Lisp.  You're perfectly free to
fall into the backwaters of computing.

>And don't
>invalidate all of the text books, articles, etc that have already been
>written and used for many years!

Too late, the 1959 LISP Programmers Manual is already invalidated.

>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"...

Methinks you're getting rather inconsistent.  On the one hand, you accuse
CL of being specified by including everybody's favorite feature (presumably
from pre-existing Lisps);  on the other hand, you say that it's a new
language that is incompatible with Lisp.  Both of these assertions can
be true only if the pre-existing Lisps were fundamentally incompatible.
But you've already claimed that they are all "Real Lisp" and basically
the same!

>There are a lot of good things in CL, but it's a mammoth compromise and you
>and I both know it.

Suppose the Common Lisp committee had all been dropping acid and decided
UCI Lisp was "the Ultimate".  Non-UCI-Lispers would have promptly ignored
the committee and continued to go their own ways.  It is interesting to
note that the Lisp community has been converging faster on Common Lisp
than the DoD types have been standardizing on Ada, and there has been no
official dictum that Common Lisp will be used for projects.  There is a
lot to be said for compromise when the circumstances demand it.

>There are tons of problems

UCI Lisp (and Franz and PSL and Interlisp) have megatons of problems then.

>>Perhaps you should try a non-broken Common Lisp then...
>>Not in clever implementations...
>
>Where are these  clever, non-broken Common LISPs?

PCLS isn't bad, although it's a subset.  But then it's had only about
one person-year put into it.  Try VAXLisp or Lucid Common Lisp (which
has a hot compiler) or HP Common Lisp or Symbolics Common Lisp or
Kyoto Common Lisp.

>the results are forcing many firms to
>recreate LISP in C to get decent performance for their ES shells.

I don't know which companies you might be referring to, but the ES
shells I've had occasion to examine have such brain-damaged algorithms
no amount of translating to various languages is going to help them.
Recall the usual shibboleths about benchmarking and performance analysis...

>The only "non-broken" versions I am aware of are re-written SPICE!

PCLS has a couple functions stolen from Spice, but it's mostly new code.
Symbolics Common Lisp is all their own.  HP is careful to emphasize that
their Common Lisp is not based on Spice, but that's not necessarily an
advantage.  Spice is good code.  You could do a lot worse, especially if
you don't pay attention to the specification.

>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).

MIT isn't some sort of magical place whence optimal correct code appears
every so often.  There aren't many people there willing to build their
own Lisp anymore; they either go with a commercial version or hack Scheme
instead (a lot of Common Lisp features derive from Scheme, by the way).

>You may not know who I am; that doesn't make me an illiterate idiot!

I don't *care* who you are; I just go by your statements.

>I've probably been around a LOT longer than you have,

Probably true - certainly I can't get into an early 70s Lisp frame
of mind without working at it.

>and probably have a much wider range of experience,

There used to be people with a great deal of experience designing oared
galleys, but they weren't very helpful with modern programming languages.

>we have more LISP designs than you'll ever see

So where are all these great Lisp designs eh?  Are any of them implemented?
Why don't you subject them to public scrutiny?

>-JJ, CONSART Systems Inc.

Probably everybody is getting tired of this.  There is a particular topic
that I would be glad to discuss further, which is the rationale for the
various design decisions that went into Common Lisp.  Many people have asked
about various features good or bad, and when I've gone to look into my
historical material, there have been some interesting discoveries.  For
instance, did you know that an early draft (the "Swiss Cheese Edition")
proposed no less than 578 functions to operate on sequences?  It was some
time before it occurred to anyone that keywords might reduce the number
of functions.  So far, I've been able to find some pretty solid reasons
even for some of the most bizarre Common Lisp features.  So if anybody
has questions, post or mail me, and I'll try to find out the real story
and explain it.

							stan shebs