Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!ram
From: ram@spice.cs.cmu.edu.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1137@spice.cs.cmu.edu>
Date: Sun, 15-Feb-87 17:07:20 EST
Article-I.D.: spice.1137
Posted: Sun Feb 15 17:07:20 1987
Date-Received: Mon, 16-Feb-87 03:45:37 EST
References: <2545@well.UUCP> <47400003@uicsrd>
Organization: Carnegie-Mellon University, CS/RI
Lines: 74


>Subject: Re: Against the Tide of Common LISP
>Date: 13 Feb 87 19:00:00 GMT
>Nf-From: uicsrd.CSRD.UIUC.EDU!sharma    Feb 13 13:00:00 1987
>
>
>	There is a pretty good critique of Common Lisp in :
>
>	"A Critique of Common Lisp" by Rodney Brooks and Richard Gabriel 
>(Stanford). It appeared in the proceedings of the 1984 ACM Symposium on
>Lisp and Functional Programming.

Yeah, this paper is reasonably coherent, but should be taken with a grain 
of salt.  Some of the arguments in it are semi-bogus in that they present a
problem, but don't present simple, commonly used solutions that largely
solve the problem.

For example, in one section complaining about the inefficiency of the
complex calling mechanisms and their use in langauge primitives, they
basically construct a straw man out of SUBST (or some similar function).

What they do is observe that SUBST is required to take keywords in Common
Lisp and that the obvious implementation of SUBST is recursive.  From this
they leap to the conclusion that a Common Lisp SUBST must gather all the
incoming keys into a rest arg and then use APPLY to pass the keys into
recursive invocations.  If this was really necessary, then it would be a
major efficiency problem.  Fortunately, this is easily fixed by writing an
internal SUBST that takes normal positional arguments, and then making the
SUBST function call this with the parsed keywords.  It is also easy to make
the compiler call the internal function directly, totally avoiding keyword
overhead.

Now presumably the authors knew that this overhead could be avoided by a
modest increment in complexity, but this isn't at all obvious to readers not
familiar with Common Lisp implementation techniques.

As I remember, the paper also complained about the excessive hair in the
Common Lisp ARRAY type preventing the obvious implementation.  I agree that
adjustable and displaced arrays are largely useless, and not worth the
overhead.  There is no doubt that they got in the language because lisp
machine compatibility was our number one compatibility priority.  The
element of bogosity comes into the argument when they negelect to mention
Common Lisp's SIMPLE-ARRAY type which can be used as a declaration to tell
the system that you haven't done anything wierd with this array, and it can
be accessed in a reasonable fashion.  This invalidates any argument of
inherent inefficiency of Common Lisp arrays, although it does impose on the
user a bit by requiring the declaration.

Probably the best criticism that they leveled against Common Lisp was aimed
at the numeric types and operations.  Since Common Lisp only supports generic
arithmetic, extensive declarations and at least some compiler smarts are
required to generate good code for conventional architectures.  On the other
hand, I think that there are powerful cleanliness and portability arguments
in favor of the generic arithmetic decision.

The COMPLEX, RATIO and to a lesser degree BIGNUM types also require
substantial work to implement, yet are not used all that much by "ordinary"
code (whatever that is).  A lot of the complexity of numbers in Common Lisp 
was motivated by a desire to "do numbers right" in hopes that Common Lisp
would be taken seriously for number crunching.  This is definitely a break
with the past, when most implementations had poorly defined and implemented
floating point support.

I also point out that, despite any misgivings voiced in the paper, Gabriel
is a major player in Lucid Inc., whose sole product is a Common Lisp 
implementation.  Evendently he believes that it is a practical, real-world
programming language.

I think that there is a good chance that Common Lisp will become the
"FORTRAN of Lisps".  Some of the constructs will seem bizzare, and many of
the restrictions will seem arbitrary; nobody will attempt to defend it
esthetically, but many people will get lots of work done.

  Rob