Date: Fri, 14 Jun 85 13:09 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Fri, 14 Jun 85 09:09:45 EDT
From: greek@DEC-HUDSON
It seems to me that, since *FEATURES* is a "global" variable, the items
in the list should not be package-specific. The features should pertain
to the LISP system as a whole, specifying things which parameterize the
system.
If a package wants to itemize features within it, that should be done
with something inside the package (special variable or function).
Furthermore, even the existence of a package isn't a feature, but rather
is noted by the presence of its name in *MODULES*. It's not even
clear to me that *FEATURES* isn't a constant, but that might be a little
radical.
In light of my opinion, features can only be simple symbols, all present
in the LISP package. Right?
The problem with that idea is that putting a symbol into the LISP package makes
that symbol be shared among all packages except those that explicitly shadow it.
Thus it is not a good idea to put a lot of extra symbols into the LISP package
in addition to the ones listed in the manual. If *FEATURES* were a constant,
controlled solely by the implementation, the problem would simply be that
different implementations would have different symbols in the LISP package,
which could be lived with (it happens anyway). But the #+ and #- syntaxes are
quite convenient and many large programs want to push their own symbols onto
*FEATURES*. I don't think it's at all a good idea for such symbols to also be
exported from the LISP package. And it would be silly to have two versions of
#+, one for "system features" and the other for "user features."
The main reason the KEYWORD package exists is to serve as a flat namespace
that, unlike the LISP package, has no effect on inter-package sharing. Thus
I think the KEYWORD package is the right one for features.
I dislike the idea of saying package doesn't matter on features. There was a big
hassle in Maclisp years ago because two compatible implementations of strings both
wanted to use the name STRING. If one could have done #+JOE:STRING and #+BILL:STRING,
we'd have been OK.
I'm willing to go so far as to say that common features which we wish to standardize
meanings for might want to go on the keyword package and that user-defined features
could be legislated not to be allowed there. From this, we could further define that
#+ and #- would do the effect of
(LET ((PACKAGE (FIND-PACKAGE "KEYWORD"))) (READ))
so that #+FOO was like #+:FOO. So, for example, if COMPLEX was something we expected
some implementations to fail to provide for some reason, we might say legislate
that implementations providing it must have a :COMPLEX feature and people could use
#+COMPLEX.
But people providing private features would be forced to do #+FOO:COMPLEX.
We should stipulate that package-not-found errors after #+ and #- are to be treated
as if the feature were missing.
Would people buy this or some close variation thereof? It gets around the problem of
having to make feature names go on LISP (since everything is on keyword) without
losing package information and without causing people to type package names in common
(pun?) situations.