Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!husc6!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <4296@utah-cs.UUCP>
Date: Sat, 14-Feb-87 13:16:05 EST
Article-I.D.: utah-cs.4296
Posted: Sat Feb 14 13:16:05 1987
Date-Received: Sun, 15-Feb-87 04:41:43 EST
References: <2581@well.UUCP> <2582@well.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: University of Utah CS Dept
Lines: 83

I really shouldn't respond to this crud, but as one of the people who has
spent quite a bit of time thinking about CL subsets,  I wanted to correct
the following misstatement:

In article <2582@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes:

>>The CORE of Common Lisp, which is
>>lexical scoping, 22 special forms, some data types, and
>>evaluation/declaration rules, is not slow at all.  It is not as elegant as
>>Scheme, true, there is certainly a manageable set of primitives.  Quite a
>>bit of Common Lisp can be implemented in itself.
>
>If there is a CORE, why couldn't the committee to produce a subset come
>up with anything?  Certainly *parts* of it can be implemented in itself;
>why should they then be considered a critical part of the language that
>can't be done without?

First, there have been several proposals for subsets.  They typically have
these problems:

1. Missing but desired features.  Even within Utah, a subset that would make
everyone here happy contains over 400 functions.  About the only thing
that everybody agrees on is that NSUBSTITUTE-IF-NOT should be omitted.
If you take all groups, there is even more variance about what is important.

2. Lack of orthogonality.  If CL had a MEMBER that does EQUAL tests and a
MEMQ that does EQ tests, but only an ASSOC that does EQUAL tests and no ASSQ,
you can bet that everybody would moan and complain about it being
"non-orthogonal".  Similarly for UNION and UNIONQ, INTERSECTION and INTER-
SECTIONQ, and so on.  It's a no-win situation for designers;  either they
add strange functions and be accused of making a fat language, or leave them
out and be accused of inconsistency.

3. Semantic interconnection.  Parts of a design interact with each other.
The time functions use the Universal Time standard that counts in seconds
from 1/1/1900.  It's a better choice than the Unix pseudo-standard 1/1/1970,
but unfortunately universal time is almost always a bignum, so you have to
have bignums around.  Or consider keywords.  If you decide that keywords
to functions are bad and throw them out, what do you do about DEFSTRUCT
constructor functions?  I know what's been done in the past, and it's enough
to make one retch  - like making constructor macros instead of functions :-( .
Again it's a no-win for designers, since if they didn't make things inter-
connected, people would bitch about needless duplication of language concepts.
There is still quite a bit of interest in trying to modularize, but it's
beyond the state of the art.  (EuLisp was supposed to be like that, and it
seems to have bogged down...)

4. Inconsistent extensions.  If the standard does not say anything about
a SORT function, then inevitably several people will write mutually incon-
sistent packages for sorting.  This generates two sub-problems:  first, 
programs are continually loading this module or that module.  PSL for instance
has hundreds of modules that can be loaded, but it's a pain in practice to
forget one of them (and autoloading has its disadvantages as well).  More
importantly, one can get gray hairs trying to integrate two programs each
using a SORT with different arguments and behavior (maybe one package needs
a destructive SORT, and the other a non-destructive one).  If you standardize
SORT, the problems go away.

So those are some of the more significant reasons why no subsets are favored.
I urge people to get copies of old drafts of CL and the archived discussions.
They're extremely interesting, and one gets a sense of the number of competing
interests that had to make what they considered to be major compromises
in order to produce anything at all.  Would-be introducers of new Lisp
dialects should especially study the material and reflect on their chances
of success...

>...there is 1 major pieces of baggage which I believe has more adverse
>affect on CL than anything else and that is the absurd complexity
>of the LAMBDA list!

In PCLS we do interprocedural analysis to eliminate completely the overhead
of complex lambdas, by reducing to simple calls.  It's extremely effective.
See Utah PASS Project Opnote 86-01 for details.

>Part of the
>problem with the enormous amount of effort devoted to Common LISP
>is it's stifling of other work in the United States.

That's a problem with any standard.  Who is it that's being stifled
anyway?  Not me...

> Jeffrey M. Jacobs
							stan shebs