Common Lisp Subset

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

    Out of curiousity, I went through the Spice Lisp sources and
counted all the code that we could eliminate if we were implementing
your subset instead of Common Lisp.  I counted about 12,000 lines of
code.  This is out of the 40,000+ lines of code in Spice Lisp
which implement the Common Lisp specification.

    These figures don't include the compiler, but then none of your
restrictions help the compiler a great deal.  The only significant one
is elimination of keyword args.

    Largely what you propose is the elimination of many facilities which
are easily defined in terms of other facilities.  This may be a good
criterion for eliminating them on esthetic grounds, but it isn't the
best way to reduce resource requirements.  An example is the
restrictions on the irrational functions.  Your changes only eliminate
25% of our irrational code.  This is because the strange irrational
functions and complexes are defined in terms of the basic functions
which you do require.

    In other cases, things that you eliminate will have to exist
anyway to support things that you require.  For example, Decode-Float
is used to implement the irrational functions.

    If you set out to build an entire implementation with minimal
memory usage, then you could probably build one quite a bit smaller
than Spice Lisp.  It is unclear whether in such a minimal
implementation, the effect of your restrictions would be larger or
smaller than in Spice Lisp.  Many of the features that you propose to
eliminate are quite amenable to simplification at the cost of
efficiency, possibly more so than the ones to propose to retain.

    Some of your restrictions are legal in Common Lisp
implementations.  Declarations may be ignored, THE is ignorable, and
several implementations don't have DISASSEMBLE. 

    You have avoided eliminating the big "iceberg" features such as
full lexical scoping and full rational arithmetic.  These are features
which take little text to describe, but much code to implement.  This
does make the subsetting less traumatic, but it isn't the most
effective way to eliminate resource requirements.

    It seems that you set out to eliminate 50% of the tokens from the
language, and have done so.  In the process of eliminating everything
that was easy to eliminate, you have only reduced the real complexity
of the language by about 25%.  While it is true that there will always
be a price/performance range in computers, a 25% reduction in required
performance will probably bring a smaller reduction in price.  It is
also true that there are effective lower bounds on price and
performance.

    Today it is hard to get a personal computer with less than 64k of
memory; ten years ago it was hard to get a personal computer with more
then 64k.  The question is how long is the performance window of
subset Common Lisp v.s. full Common Lisp going to be open.  In your
example of a too-small subset, you mentioned miminal basic.  The real
problem with minimal basic is that there is no machine today which
cannot run a full basic.  Remember the "standard" 4k basic and the
"extended" 16k basic?  It's no surprise you don't hear much about 2k
tiny basics anymore.

  Rob