a standardization proposal

[SANDRA <LOOSEMORE@UTAH-20.ARPA>]

It seems like most of the ongoing problems with Common Lisp derive from
places in the manual where there has been some effort made to standardize
inherently non-portable features.  The net result is that many
implementations are forced to provide support for functions that are
essentially useless, but the standard is still too weak to enforce that
programs that attempt to use these features be portable.  

The business about character bits and font is a perfect example:  any
program that uses them is potentially non-portable anyway, so it's
rather silly to insist that every implementation provide functions
for dealing with them.

As a solution to this, I would like to see things in Common Lisp divided
into two distinct categories:  (1) things that *every* implementation
*must* provide to call itself "Common Lisp"; and (2) things that an
implementation need not provide, but for which a standardized interface is
desirable.  Moreover, I would like to see things in category (2) given
standardized names which can be present in *features*, so that you can 
readily tell whether or not the implementation supports that feature.

So, if somebody has a proposal for handling generalized input events (or
Kanji characters or screen manipulation functions or whatever) that is
generally acceptable to others interested in implementing such a feature,
it could be given a standard name and documented in the manual as being 
optional.  Implementors that aren't interested in it, or that can't
support it given the constraints of the operating system environment or
whatever, are under no obligation to provide it.  Programs that depend
on the feature can test for its presence before using it.

This approach would also be useful for defining various levels of CL
subsets.  For example, does an implementation designed for educational
use on microcomputers really need to support complex numbers and four
kinds of floats?  Removing complex numbers from the language core and
making it an optional feature would at least give us a standardized way of
talking about what things a given implementation does and doesn't support.

I believe that there was a similar proposal to break the language up
into a "core" plus various modules around at the time of the Swiss Cheese 
edition of the manual, but it was removed for lack of interest.  Are
people still of the opinion that this is a useless idea, or is there
more motivation for it now that we have a bit more experience with the
language?

-Sandra Loosemore
-------