🚀 go-pugleaf

> Jeff Jacobs writes:

> 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.
----------
I have to agree with Hedrick and Shebs and one of the primary
philosophies of CL -- the compiled environment and the interpreted
environment should behave the same way to the greatest extent possible.
The notion of dynamic scoping turning into lexical at compilation is
appalling.

On the other hand, I'm not completely pleased with the CL approach,
either.  There are times when scoping doesn't do what those of us coming
from the non-Lisp side would expect.
----------
>  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?
----------
Isn't Lucid sui generis?  Franz Common claims to be, but I gather
you consider it to be broken (I haven't used it).
----------
>  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.
----------
There's plenty of discussion on the CL mailing list about problems
with the document, but it's not all that bad.  A document specifying
the complete details of each function (and therefore repeating tons
of material common do other functions doing related things) would
have been MUCH bigger.  Such a thing would be useful, God knows, but
for a first statement of the principles and contents of the language,
CLtL is much preferable.  A more tutorial approach would not have been
as effective either.

I agree with your complaint about the fonts used for non-text material.
Personally, I would have preferred a non-monospaced font and something
denser (thus standing out better).  I certainly would NOT have supported
use of upper-case, which is fine for occasional emphasis but much
less readable.
----------
>  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.

> 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!
----------
Well, yes and no.  You can't do a derivative language with new features
without changing the meaning of some of the existing constructs.  It's
vital, of course, that you point things out sufficiently clearly that
the careful reader (anyone who skims this kind of document gets
exactly what she deserves) can take note of what has changed.  The
book is reasonably careful about giving explicit notice about such
functions (which your original posting actually complained about).

MEMBER, by the way, does not default to EQ testing, it defaults
to EQL testing.  It should not be a big deal to make that kind
of change in existing code -- just change the name of the function
in your existing code and provide a macro supporting your name
in terms of the underlying CL primitive (I'm sure that kind of change
is second nature to you anyway, given the kind of Lisp background
you have).

The number one goal of CL was to provide a common base for new Lisp
development.  It seems to be the case that the world of AI vendors
has bought that goal -- everybody seems to be building versions of
CL, even Xerox.  Nobody would expect the first version of something as
big as CL to be definitive, but conforming implementations should be
close enough that porting will be much easier than in the past.
Experience should indicate the specific areas that need further work in
specifying a formal standard (an effort now under way) and moving
towards common understanding of the issues that were insufficiently
specified in CLtL.


-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms