>>9Here's my rationale: If Scheme were a lisp, it would call itself a
Lisp. Does Java call itself a C? No, because it's not a C.
Moreover, if scheme were a lisp, then ML would be a lisp. As would
haskell, logo, perl, ruby, and lots of other languages which have
closures and recusive functions. ML and scheme are far more similar to
each other than either is to Common Lisp.
Scheme is not a Lisp IMO because of two types of reasons: first,
technical, which have been argued on this group ad nauseam (the
deepest difference there to me is that a scheme program is defined as
a string of characters whereas a CL program is defined as a sequence
of lists of Lisp objects. This may seem pedantic or trivial but a lot
of different design decisions follow from this. It makes Scheme an
infix member of the Algol language family.); but more important,
philosophically. The Scheme community has evolved a set of values at
odds with the spirit of Lisp: the goal for simplicity at the expense
of convenience (compare the concept of CL's $item designators with the
design of convert stuff explicitly like Scheme's exact->inexact), the
goal of only giving basic blocks and letting you assemble stuff
yourself (call/cc isn't a replacement for a worked out exception
system).
To sum it up with a Ritchie quote: "Some languages were meant to get
work done, some were meant to prove a point." I put Lisp in the first
category and Scheme and Haskell in the second. (See also the reliance on
tail call elimination to be able to prove the point that a looping
construct isn't necessary.)