Newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!usenet.eel.ufl.edu!news.mathworks.com!nntp.primenet.com!mcsun!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Common LISP: The Next Generation
Message-ID: <DwyJ2G.13F.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <4vp93n$fpk@snotra.harlequin.co.uk> <joswig-2608961320440001@news.lavielle.com> <wb0bufy85cw.fsf@goober.graphics.cs.cmu.edu>
Date: Fri, 30 Aug 1996 15:30:15 GMT
Lines: 192
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:22450 comp.lang.dylan:7089 comp.lang.scheme:16669

Scott Draves wrote a few days back

   CommonLISP is the expediant compromise and union of (then) existing
   lisp systems.  Scheme was the intersection: everything that they could
   agree was Right.

He now says he "haven't said anything negative about" Common Lisp.
But I'd call "expediant compromise" rather negative, and talk such
as "union of existing lisps" reinforces widespread prejudices and
misconceptions.  

In any case, he has now offered a clarification:

On 28 Aug 1996 15:06:25 -0400, spot@goober.graphics.cs.cmu.edu (Scott Draves)
wrote (in reply to me):

> apparantly, i was not clear.

> i wasn't speaking about historical sequence (which i know), but rather
> of end products of design philosophy, process, and objectives applied to
> feature selection.  loosely, that `intersection' produces the smallest
> product by including essential features agreed upon by everyone, and
> that union includes features found to be useful, but that one often
> can live without (such as macros and packages) or were missing from
> one of the predecessors (eg complex arithmetic).

I did have history in mind when talking about whether Scheme "threw
out" things from CL, but not when talking about union and intersection.
I was talking about the relationships between languages and the
mechanism by which features were selected, not history, though that's
still (it seems) a partial misunderstanding of what you meant.

However, I'd still say you're wrong.  Common Lisp was an intersection,
not a union.  It was what could be agreed on.  Ok, it was often by
majority vote, rather than requiring that "everyone" agree; and some
of what was included was not "essential" -- but neither of those are
necessary to an intersection.

Here I am rejection your definition of "union", because I think it is
seriously misleading to say "union" just because there's inclusion of
features that were not "essential" or were missing from predecessors.
(Neither a (set) union nor an intersection brings in features missing
from predecessors, BTW.)

Moreover, both Scheme and Common Lisp include features that one
can live without; but some of these "nonessential" features --
such as macros in CL -- are central to what makes the language
what it is and worth using.  One can live without call/cc and
a number of other things in Scheme.  One can even live without
symbols and lists, as programming in the vast majority of programming
languages has shown.

What you're left with is this: Scheme is far smaller than Common Lisp,
and the Scheme designers want Scheme to be a language with a small
number of powerful features, while the CL designers were more
pragmatic and cared more about overall functionality than size.  But
this it not to say the CL designers wanted maximal functionality by
including everything useful they could find, nor that they cared
nothing about size.  For instance, the 24 special operators in CLtL
reflect a significant degree of care in the selection of primitives;
and CL left out or cleaned up much that was in earlier Lisps.

As CL was developed by X3J13, in many cases extending the language
of CLtL, it became somewhat messier and some things (such as the full
LOOP macro) were included despite a widespread feeling that they
weren't really Right.  But we can still see selection, cleanup,
and generalization -- e.g. in CLOS.

> So when i say Scheme `threw out' things form Common Lisp, i didn't
> mean that they were reading the Common lisp standard and removed
> things from it, i meant that the designers considered many of the same
> features, but decided not to included them.

It's misleading to say they threw out things from Common Lisp when
instead they were rejecting (and often not considering at all) things
from MacLisp and maybe some other Lisps around in the 70s or early
80s (such as various NILs).  And many of these things either didn't
appear at all in Common Lisp or took a different form.

Your reference to the CL standard is a herring of deepest red.
Common Lisp was around well before the standard.

(I hope, BTW, that you're not going to argue that because the Scheme
designers were aware of what was in Common Lisp throughout the period
of CL design and standardization, we can say they "threw out"
everything in CL they didn't adopt for Scheme.  If you don't accept
that "threw out" is prejudicial language, I hope you'll at least
recognize that more neutral language is available.)

> remember the committe operated by unanimous consent.

Remember that Scheme was not initially designed by a committee
and that the current Scheme is not very far from the original.
(Names have changed to those from T, some lightweight process
stuff was removed, ...; but the they both "look like Scheme".)

The RnRS authors took an existing, small, language and modified it
using a process that made change difficult.  The existing language
came from a time when Lisps in general were often fairly small.

Common Lisp in effect started from something like 4 larger, and
still developing languages, successors to MacLisp.  The aim was,
in effect, to agree on a common subset of what those languages
_would be_ (not what they were).  The people involved were working
on or with similar languages, and they naturally agreed on a
fairly wide range of features.  (If a wider range of languages had
been involved, agreement would have been less.)  And the mechanisms
for changing the language made changes (including extensions)
easier than for Scheme.

So there are factors at work apart from deliberate design.

I've been involved in the design of several languages in the Lisp
family, and I've seen a certain pattern there and for some other
languages: there's fairly rapid and easy agreement on a range of
features, and then agreement becomes much harder.  Features that
look like the sort of thing that would have been easily agreed to
earlier prove controversial; arguments for and against occupy more
time and a consensus does not emerge.  That something is not Clearly
Right now seems to count effectively against it, though similarly
imperfect things were accepted before.  (For instace, if "load"
were not already in Scheme, it would probably be impossible to add
it.  If records had been in, say, the 1st "Revised Report", Scheme
would probably still have them.)

Anyway, this seems to be largely independent of what the designers
would say their design aims are.  (The aims might remain pretty
much constant throughout, for instance.)

> compatability, one of the core goals of Common Lisp, is inherently a
> `union' philosophy.  something you have to agree on once (like if
> variables are by default lexical or dynamic, and how many namespaces
> there are), but many, many features exist as standard/library
> functions or data types which coexist, ie can be unioned.

"Can be unioned" and "are unioned" are two different things.

Common Lisp is fairly compatible with Lisps close to MacLisp.  With
a fairly small amount of compatibility code, I can write fairly
"natural" code that works in both Franz Lisp (which is very like
MacLisp) and Common Lisp.  (I pick Franz, because then it's something
I've actually done.)

Now Franz Lisp has hunks, to be compatible with PDP-10 MacLisp.
_There's_ compatibility for you.  CL does not have hunks, just
one of the many things in MacLisp and the various MacLisp successors
mentioned above that are not in Common Lisp.

CLtL mentions compatibility with Lisps outside the MacLisp group,
e.g. InterLisp; but you'd be hard pressed to find much in CL that
results from this "aim".

> from [Reese82] from [Evolution of Lisp]

>    we have refrained from supporting features that we didn't feel
>    completely right about. ... 

> [Evolution of Lisp] also says that eventually the common lisp group
> felt that their task was finding The Right Thing as well, but i don't
> believe this is true to the extent that it is in Scheme.

It's hard to say.  The authors of [Evolution of Lisp] are in a better
position to know than most.  But the CL and Scheme designers had a
different notion of what the Right Thing was.  (But that's not quire
right either.  Some, at least, took the view that there wasn't a
single Right Thing.)

> jeff> Part of the reason Common Lisp is less popular than it might be
> jeff> is that people keep saying false things about it.

> pu-leeze relax jeff.  i think Common Lisp is a wonderful language.  i
> haven't said anything negative about it.

It looks to me like you've said things that are at best misleading
and that make Common Lisp look worse than it is.

Perhaps you don't know this, but many people think Common Lisp is
a union of almost everything found in earlier Lisps.  When they
see both lexical and dynamic scoping, that's what they see: the
CL designers just threw in everything.  But in reality the way
variables work in CL is not a union of everything around earlier.
It's a cleanup and generalization of what was in MacLisp and
similar Lisps.  And it's not compatible with those earlier Lisps,
only (at most) with fairly clean subsets of those languages.

If you don't mean to say anything negative, there are probably ways to
make your point that I would not object to; but it's unlikely that
anything that talks of expedient compromise, labels Common Lisp a
union, or fails to recognize the extent to which CL was a cleanup
compared to earlier Lisps, will be among them.

-- jd
