[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
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.