features

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Fri, 14 Jun 1985  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    It was clear at the time we let #+ and #- into the language that these
    were total kludges and were being kept around almost entirely for
    reasons of compatibility with existing code.

I disagree with this. #+ and #- are necessary because implementations invariably
differ in all kinds of unexpected ways and sometimes it is necessary (both in
program and data files) to completely blindfold READ to gross kludges. While I
think it's reasonable to describe this as a total kludge, I think you're kidding
yourself to think such kludges are a thing of the past and something that will
not continue to occur. In spite of a desire I'm sure we all have to never resort
to these tools, they serve a vital function and should be made as convenient and
as well-defined as possible for those situations where they turn out to be needed.

    ... I think it would be a major mistake to try to extend them by letting them
    take an arbitrary extension to evaluate ... 

I certainly agree with this part. #. can handle the more complicated situations.

    I think that by far the simplest solution is to make #+foo treat the
    symbol FOO as a keyword, despite the lack of a leading colon in this
    context.  This minimizes the possibilities for subtle package lossage of
    the type Moon describes.  Yes, it would then be possible that packages
    developed in total ignorance of each other might choose confliciting
    feature keywords; on the other hand, such packages have an equally great
    chance of choosing conflicting package names, so there has to be some
    modest amount of coordination if they are to run together.  I think that
    this is a change and not a clarification, however -- there's no way to
    read the current manual as specifying this conversion to keywords...

Statements like "yes, it would then be possible ..." and such which suggest
that you want to ignore the "hard cases" completely miss the point. #+ and #-
have their major use in the strangest situations and flattening the namespace
will not serve to make things better.

    I think that putting all these symbols in the Lisp package (as external
    symbols) is not workable.  For ont thing, this will often result in some
    internal symbol in Lisp being unintentionally made external, and then
    when another package imports Lisp it is in for some unpleasant
    surprises....

As I said in an earlier message, I am content to have a fixed and advertised
set of Common-Lisp approved features reside on the keyword package, but I 
very strongly oppose any use of the keyword package for any application which
involves an user-extensible set of names (such as the features list). 
In my opinion, user-defined features should must be packaged (and expressly 
not on the keyword package); refer to my earlier message on this subject for
details.

    The manual is quite clear that the features are to be symbols (or lists
    that are boolean combinations of symbols), and I don't see any reason to
    extend that.  #+3600 can read the string "3600" as the name of a
    (keyword) symbol.  This avoids all radix lossage.

I guess I really don't like this because it destroys the simple user model that
READ is involved and it makes one wonder if #+FOO:3600 will read as FOO:/3600
or just :/3600.