Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!well!jjacobs
From: jjacobs@well.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <2582@well.UUCP>
Date: Fri, 13-Feb-87 23:39:41 EST
Article-I.D.: well.2582
Posted: Fri Feb 13 23:39:41 1987
Date-Received: Sun, 15-Feb-87 00:27:38 EST
References: <2581@well.UUCP>
Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 110


In 138@lmi-angel.UUCP, Bob Krajewski writes:

>>I can accept SCHEME, where you always know
>>that it's lexical, but CL could drive you crazy (especially if you were 
>>testing/debugging other people's code).
>
>Huh ?  Whether or not a variable is lexical can be determined by looking at
>its lexical context (practically an axiom, eh ?).  So if it's being used
>freely, you can assume it's special.

I was referring to *debugging* code, not compiling it.  In examining
a function, it is not *lexically* apparent whether an argument is
SPECIAL or local, i.e. if I enter

(DEFUN CONFUSE_ME (X Y Z)...

Now, you tell me if the variables are going to be dynamic or lexical?
Was a DEFVAR or a PROCLAIM issued earlier?  No way to tell, is
there?

And should I assume that in

(DEFUN FOO (FUM FIE) (LIST FUM FIE F1E))

F1E is SPECIAL?  Would you?  Especially when someone else wrote it?

Common LISP makes an old problem worse, not better.

>
>Well, maybe having a function like MAP (takes a result type, maps over ANY
>combination of sequences) is a pain to implement, but the fact there is
>quite a bit of baggage in the generic sequence functions shouldn't slow down
>parts of the system that don't use it.  The CORE of Common Lisp, which is
>lexical scoping, 22 special forms, some data types, and
>evaluation/declaration rules, is not slow at all.  It is not as elegant as
>Scheme, true, there is certainly a manageable set of primitives.  Quite a
>bit of Common Lisp can be implemented in itself.
>

If there is a CORE, why couldn't the committee to produce a subset come
up with anything?  Certainly *parts* of it can be implemented in itself;
why should they then be considered a critical part of the language that
can't be done without?

I'd love to believe that what you describe is a *real* core, but I can't.
The book and the rest of the CL community say otherwise!

I will address the issue of baggage in the near future, let me state that
there is 1 major pieces of baggage which I believe has more adverse
affect on CL than anything else and that is the absurd complexity
of the LAMBDA list!  Function calling will never be the same :-)

>Well, (SETF) does nothing.  You probably wouldn't write this, but again, a
>macro would find it useful.  Should (LIST) signal an error too ?

One of the most common errors found in software is improper number
of arguments.  This has plagued more programs and languages than
I care to recall.  Common LISP has given up the built-in error
checking of previous LISPs.

A macro which generates a function with zero arguments should
almost certainly be checking for the correct number of arguments.

>>Care to explain this to a "beginner"?  Not to mention that SETF is a
>>MACRO, by definition, which will always take longer to evaluate.
>
>Since you're a beginner, by your own admission, why do you think that a form
>which is a macro call will be noticeably more expensive (in the interpreter,
>the compiled case can't ever be slower) ?

You misunderstand me; I'm not a beginner.  In fact, I'm an old fogey :-)
I was one of the co-developers of UCI LISP, and crawled through
INTERLISP, MACLISP and of course Stanford LISP probably before
you could read :-)

You know perfectly well that interpreting macros takes more time!
First you have to EVAL the form, and then give the result to EVAL
again!  (And I *don't* consider it kosher to destructively expand
without the user's control).

>(Oh, by the way, they reversed the arguments to CONS, ha ha...)

You mean (CONS 'A 'B) => (B . A)? :-)

>It won't introduce bugs into new code written by people who read the manual
>and understand the interface and semantics of MEMBER.  Your (legitimate)
>obstacle is porting ``traditional Lisp'' code to Common Lisp.

Hey, CLtL specically states that one objective is to remain compatible
as much as possible.  Now MEMBER is a very basic primitive, going
back even before my time!

>Well, the main winning alternative is even further away from your Real Lisp
>than Common Lisp is: Scheme, or T, which can be pretty much turned in a
>systems programming language.-- 
>Robert P. Krajewski

What about Le_LISP, or the proposed ISO/EU-LISP?  Part of the
problem with the enormous amount of effort devoted to Common LISP
is it's stifling of other work in the United States.

 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: jjacobs@well.UUCP