🚀 go-pugleaf

>References:<5194@topaz.RUTGERS.EDU <1311@well.UUCP> <3827@utah-cs.UUCP>
In <5194@topaz.RUTGERS.EDU>, Charles Hedrick says:

>In general, I agree with Shebs' response.  A couple more things:

Mr. Hedrick does not state what points he agrees with.  However, he then
goes on to say:

>There is nothing in CL that makes a fast interpreter impossible.
>There is plenty that makes it difficult.  The DEC-20 implementation
>has an interpreter that is reasonably fast.  The major speed problem
>is caused by lexical bindings...

I fail to see where Hedrick disagrees with me, unless it's my use of the
word "impossible".  Since the original article was deliberately "flameboyant"
I'll be glad to downgrade "impossible" to "plenty difficult" <grin>.

>Personally I would have wished for CL to be smaller.  As the manager
>of a number of timesharing systems, I cringe at a Lisp where each user
>takes 8 MB of swap space.

This also sounds suspiciously like agreement with my position about CL
being a bit overgrown.  Just how many UCI LISP versus CL users can a 2060 
support?

>Simple implementations are slow because 
>they have to put all of the bindings on lists, thus replacing push by
>CONS and pop by a GC.

(Note: Hedrick's original msg. had "low", not "slow").

The overhead penalty is not in the CONSing; the time for CONS should be roughly
equal to pushing the data on the stack.  The REAL overhead is in accessing
the data, whether searching a list or searching a stack.  If the value of
FOO is accessed many times, the overhead increases dramatically. In fairness,

should be pointed out that there is possibly BETTER performance in a lexically
scoped interpreter using a stack than in a deep bound dynamic environment,
as the interpreter would go the value cell if it wasn't found in the
lexical environment, as opposed to searching the entire stack.

In the case of using a list for the environment, a careful implementation
should be able to RETURN the "lexical" environment to the free list on
exit, reducing the need for GC.  (I assume that he didn't do a GC after
every function exit).

>What we get for all of
>this pain is an interpreter whose binding semantics are compatible
>with those of the compiler.  I spent several years supporing UCI Lisp.
>Many users never compiled code because when they compiled it, it
>stopped working.  The primary problem was that the binding semantics
>changed, and they suddenly had to declare lots of things "special".

 <flame on> 
The code didn't "stop working"; the programmer just didn't know
how to do a complete job.  It's 
a matter  of not being taught decent programming habits.
Versions of DWIM/Programmer's Assistant have been available for
UCI LISP since 1972, which make it very easy to keep track of necessary
SPECIALs, etc.  The notion that gets into student's heads that they
can just blindly write code without any forethought or planning is what
gives Comp. Sci. grads such a bad reputation in industry.   There's
really no excuse for failing to understand such a basic principle of
the language being used. 

Some people need to be protected from themselves;  LISP (and
assembler) are not for them.  Let them use PASCAL and M-2.
 <flame off>

Historically, the default to local/lexical compilation was an obvious
optimization, based in large part on the fact that most good LISP programmers
wrote very functional code with very little need of dynamic scoping.

>In my opinion it is worth a man-month from each implementor to get rid
>of this problem.  

A man-month? See below...

> Actually, I voted against this feature of CL.  I
> would have preferred that the compiler use "special" all the time.
>(We did this to a compiler for a variant of UCI Lisp.  It helped
>things immensely.)

You're gonna hate me for this; UCI LISP was meant to be that way when
released.  Daryle had planned to do it, but didn't
have time and forgot to tell me before he graduated.  I was so busy with
the interpreter and other things that as long as nobody reported bugs, I
didn't give the compiler much thought.  So it just fell through the cracks
<sigh>.  (I'm not sure we could have convinced Rusty, anyway). 
Development at UCI basically stopped when I left <sigh>.

If you voted against it, it sounds like we agree!

>It was turned down, I think for two reasons (1)
>This makes the compiler pay in efficiency.  Adding lexicals to the
>interpreter makes the interpreter pay in efficiency.  Since you
>compile when you want speed, it makes sense to pick the definition
>that is fastest for the compiler 

This is highly machine and implementation dependent.  There are 2 things that 
must be considered, time to perform the binding and time to access.  
Time to access is really the key to performance.  (Given the overhead
involved in CL's extended binding capabilities, time to bind might
even be cheaper <grin>).

>(2) There are a number of people who
>believe that lexical binding is safer, and who want to use lexical
>closures.

From an overall, general language design perspective, I believe that
lexical scoping is better.  But there should be a SYNTAX to go along
with it.  LISP syntax simply doesn't provide a decent distinction
between lexical and dynamic; I can go along with either one or t'other,
but not mixed.  Besides, we need at least one language with dynamic
scoping <grin>...

>A number of things said in the original posting are just wrong.  I can
>think of no way to implement SET so it works for lexically-bound
>variables in compiled code.  There are such things in UCI Lisp.  They
>are called SPECIAL.  I am reasonably sure that SET does not work with
>them.  If the manual fails to say this, it is a documentation error.

If you put on your "stupid ways to do it" cap, you could figure out a
way to do it.  But it's not really something you would WANT to do.
SET has ALWAYS been a problem, more so when interpreted than compiled,
due to the shadowing problem.  For consistency, CL should have thrown
out SET, and defined a new function, maybe SET-SYMBOL-VALUE.  But is
should NOT have changed the semantics of SET (or MEMBER).  The definition
of SET in CL is very useful; it's the name I object to.

BTW, SET should work with variables declared SPECIAL.  I'm not sure
what your comment means.

>The primary reason for SETF is for convenience in writing code that
>writes other code.  Examples are macros and code to implement flavors
>or other structured-programming constructs...
>... However researchers are now beginning to depend upon high-level
>tools.  We want a macro or other code-constructor to be able to take
>the definition of a component and be able to build code to change the
>element by sticking SETF around it.  It is precisly such large systems
>as KEE that make many of the complexities of CL necessary.

Perhaps this is why KEE is being rewritten in C :-)?  (So are most of
the other high end shells.  Want to bet that the C implementation looks
a lot like "Real LISP (RL")?

The results of using constructs like SETF (and similar features in ADA)
aren't in yet, and won't be for many years.  My personal opinion is that
they will prove undesireable due to difficulty in debugging them and
"type" problems.  I think it's better to write a more specific function
that's changeable rather than a "generic" function.  But SETF as a macro
does involve at least one more EVAL (despite what Shebs said).

>But I have no question that the things that
>made it bigger will save a number of people time, and facilitate the
>building of large systems.  My sense of things is that CL
>implementations, particularly after they have been in use of a few
>years and get tuned, will be about as fast as other Lisps.  However
>they will be enormous.  The attitude of the CL designers was "memory
>is cheap".  If you envision CL as being used for large systems on
>single-user systems, this is right.  That's certainly what the CL
>designers had in mind.  Those of us trying to run large student
>timesharing systems may have some problems with this.  It may be that
>for us a subset will prove helpful.  Or the vendors that supply
>timesharing systems may simply be more careful in their
>implementations, so that all of the code can be shared.

They also assume the CPU is cheap!!!

There's an old saying:

"LISP programmers know the VALUE of everything and the COST of nothing".

Have you seen the price for memory launched into orbit lately?
It's definitely not cheap!   how often have we heard about
"artificially intelligent" robots exploring Mars (or wherever). Given the
power and weight required for CL, you can forget that one!!!  In fact,
given the current trend, almost no delivered E.S. system will be in LISP.
"Rewriting" it in C after "prototyping" seems well on the way to becoming
an acceptable part of the process; you can bet that this will not be
economically viable in the real world.

It might be cheap when you have a University grant or DARPA to support you;
it gets a little more complicated when you have to justify a single user
station for $125,000 (or even $50,000) to a manager.  Then tell him
that once you have it working, you'll have to rewrite it!  From
a business point of view, I can get a lot VAX for my money...

I envision LISP being used for a great many things besides "large systems".
It's hard to visualize using CL for a small embedded system.

As long as I have been in the field, I have heard that LISP was big, slow
and hard to learn.  I always said that this was a myth, that reasonably
sized, efficient LISPs were available.  With CL as a standard, I will
be flat out wrong.  I think CL has it's place; I also think that the
choking off of other LISP development is a tremendous mistake.  Yet
this is exactly what is happening; implementors feel that "have" to
achieve full CL status (whatever that really is; even SPICE isn't
fully "Steele").

Disclaimer:  My articles on Common LISP are about Common LISP as defined
in Guy Steele's book.  It is specifically NOT about any particular
implementation; although I may point out deficiencies and deviations
from CL as defined in Steele, I am not attacking any implementation or
person (INCLUDING Guy Steele).  There is a great deal of work in CL;
it's the mad rush to make it a "standard" that I am against.

-Jeffrey M. Jacobs, CONSART Systems Inc., Manhattan Beach, CA
CIS:[75076,2603]
BIX:jeffjacobs