Re: several hundred ugly things

[Scott.Fahlman@B.GP.CS.CMU.EDU]

    There's some desire in some parts of ISO to make Common Lisp "smaller". I'd
    just as soon see it done carefully -- rather than with an axe. If you can
    think of several hundred things that could be done to Common Lisp that
    would make it smaller and not as ugly,  perhaps you could help name a few? 
    
The point of my comment about hundreds of ugly things was that if we throw
a few existing features out of the standard on aesthetic grounds, we would
open the door to demands that we throw hundreds of other things out.  I
thought our charter was to introduce incompatible changes only if
necessary, and not on strictly aesthetic grounds.

But to address the question you raise...

It seems to me that we could coherently divide the language into two
levels: a kernel of necessary low-level functions and special forms, and a
set of functions that can be straightforwardly implemented in terms of
these kernel mechanisms.  It would be fairly easy to assemble a body of
public-domain code that implements the outer layer, though this
implementation might not be optimally efficient for all machines.  Nobody
would want to use a language that had just the kernel stuff, but making the
division explicit might be of some use to implementors and to people
doing formal analysis of programs.

I have never seen a principled proposal for a Common Lisp subset that
includes some amount of non-kernel functionality.  If a person uses feature
X and not feature Y, then X goes in the proposed subset and Y is
"obviously" superfluous.  Unfortunately, people write different kinds of
programs and have different programming styles; if you take the union of
things that people use in practice, you end up with the current language
and then some.

Instead of inventing some arbitrary standard subset of Common Lisp -- wrong
for every application but the one the subset committee had in mind -- I
have always favored the idea of building a delivery mode into commercial
Lisp systems.  You develop your program using whatever parts of the full
language you need, then compile in a way that trims away anything that
wasn't used.  This creates a subset of Common Lisp that exactly fits the
needs of the application in question.  A simple version of this is trivial
to implement in any system that has a copying GC; with more effort, one
could eliminate parts of large functions, such as the code to implment
CIRCLE-PRINTING FORMAT's hairy numeric options, if an application doesn't
need them.  I've never understood why the commercial vendors haven't put
more effort intot his sort of thing -- seems like there would be a market
for this, especially in systems that cross-compile to PC's and Macs.

So I don't have a list of things that I think we should flush in order to
make the language smaller.  It seems to me that if we are not going to
reduce the size of the core image significantly (say, more than 20%), then
it's not worth throwing things out at all.  Why make conversion hassles for
people when there is no significant reduction in core size or language
complexity.  The only things I'd propose to throw out are those things we
can't quite get right or can't explain coherently -- the whole pathname
system comes to mind, along with *EVALHOOK* and *APPLYHOOK*.  And maybe the
compiler.  :-)

-- Scott