[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 <······@lispmachine.de>
> Subject: Re: why Common Lisp is not a lisp
> Date: Wed, 03 Sep 2003 20:01:48 +0200
> Message-ID: <····························@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
Arguably.
> - 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
issue.
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?
Pascal
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
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)