Why Common Lisp is not a Lisp, continued

[I am picking up this thread again that came to a rest some time ago. I 
am doing this because it took me relatively long to dig out an article 
referenced in the posting below.]

[I know that such topics are likely to ignite heated discussions between 
Common Lispniks and Schemers, and some find them practically irrelevant. 
But, heck, I am interested in these things, and I don't know where else 
to discuss them. ;) ]

> From: Rainer Joswig <joswig@lispmachine.de>
> Subject: Re: why Common Lisp is not a lisp
> Date: Wed, 03 Sep 2003 20:01:48 +0200
> Message-ID: <joswig-CC3C1E.20014703092003@news.fu-berlin.de>

> A few things that are IMHO desirable for Lisps:
> - easy syntax -> CL not, Scheme yes

This seems to refer to the Lisp-1 vs. Lisp-2 issue, and the need to put 
#' into your code in Common Lisp. There are good arguments for both 
sides, or put differently, both solutions have their respective trade-offs.

> - lexical binding -> CL yes but with baggage, Scheme yes

What do you mean by "baggage". I don't think you mean dynamically 
scoping, because many Scheme implementations agree that dynamic scoping 
is useful. So what do you actually mean?

> - easy language model -> CL not, Scheme yes


> - FP support -> CL yes + minus some stuff, Scheme yes

What do you mean with "minus some stuff"? CL does provide higher-order 
functions, doesn't it?

> - defined semantics -> CL no, Scheme somewhat
> Actually in my view CL is relatively unlispy.
> (large, complicated, messy, external representation is problematic
>   (Common Lisp source programs are usually only readable by
>    a full Lisp implementation -> program analyzing tools
>    at source level are problematic),
> typical IDEs often work on text instead of data structures ...).
> -> "A critique of Common Lisp" Brooks/Gabriel
> -> The death of creativity: is Common LISP a LISP-like language?',
>    John R Allen, AI Expert, 1987

The latter is the article I have been waiting so for so long. I have 
read it and it isn't very convincing IMHO. It argues mainly from a 
Scheme-like perspective without acknowledgeing other possible 
viewpoints. (I think it's rather polemic.)

The major claims of that paper seem to be:

+ The author states that Common Lisp is still a first-order language 
because functions are created by metastructural means. However, I don't 
understand what practical limitations this has. Why is this a problem? 
The explanations given in that article don't help me to understand the 

The author complains about a bad definition for FUNCTIONP. I have 
checked with the HyperSpec, and the issues he mentions seem to be resolved.

Furthermore, he criticizes FUNCALL and #'. Well, one has to accept that 
there are people out there who are willing to pay this price because of 
the advantages they allow for in other areas of the languages. I am not 
saying that the author shouldn't make his own different decision, but he 
should accept that this is not the only possible one.

+ In that same context, he says "the next thing to notice is that Common 
Lisp is a first-order language, while we've said that Scheme is a higher 
order language. It follows that Scheme cannot be considered as a "subset 
of Common Lisp".

I don't get that at all.

When you strip away the features from Scheme that make it fundamentally 
distinct from Common Lisp but that are _not_ discussed in that paper 
(i.e., continuations and space-safe tail recursion), it is pretty 
straightforward to translate Scheme code to Common Lisp code, isn't it?


P.S.: The paper by Brooks/Gabriel has been discussed in this newsgroup 
previously, so I haven't commented on it. I am currently specifically 
interested in the paper by Allen.

Pascal Costanza               University of Bonn
mailto:costanza@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)

costanza (1427)
10/14/2003 3:46:20 PM
comp.lang.lisp 16861 articles. 5 followers. Post Follow

0 Replies

Similar Articles

[PageSpeed] 20