What package are feature names resident in?

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

Was the following issue ever resolved?  I don't think I saw anything
about it other than these two messages.

    Date: 25 Apr 85  0419 PST
    From: Jon White <JLW@SU-AI.ARPA>

    Bottom of page 358 clearly suggests that #+ should READ in the expression
    following the +, and obtain symbols which are tested for MEMBERship in
    the *features* list.  So what should happen from the following fragment:
	(in-package "LUSER")
	(push 'dull *features*)
	(in-package "WINNER")
	(push 'snazzy *features*)
	(in-package "USER")
	'(a #+dull b #+snazzy c )
    Now, how long a list is the last form read?

    Consider when package LUSER is, and is not, a user of package LISP; and
    when "dull" is, and is not, an external symbol of the LISP package.

    I believe I see two schools of thought, exemplified in the several 
    implemetations I've looked at so far.  One says that feature names can be
    any lisp objects, and since luser:snazzy and winner:snazzy are two separate
    features, you have to be careful about which one you really mean.  The 
    other school says that feature names are analogous to the names of
    packages -- a kind of global namespace --  and will probably implement #+ 
    by binding *package* to some canonical place (like, the keyword package).

    I'm not sure I can give an adequate defense of either position, but
    the fact that two different implementations initialize their *features*
    lists to symbols in different packages makes it difficult to interpret
    forms like  
	#+Lispm (do-this)
    because you don't which symbol the "Lispm" will turn into.  Should you
    have to say
       #+:Lispm (do-this)
    I don't think this was intended (to have to put package qualifiers for
    feature names), but if there are two differing implemetations . . . 

    Date: Fri, 26 Apr 1985  15:11 EST
    From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>

	I believe that the issue discussed was "Should features always be
    keywords?"  The conclusion was "No, but they can be."  An implication
    of this decision is that features are packaged symbols.

The manual is not clear on this point.  I think the most likely reading
of what the manual says is that features are packaged symbols.  However,
I don't believe that that can be workable in practice.  As JonL pointed
out, it's difficult to deal with this unless you make every feature a
keyword, but then you have a lot of extra colons flying around.  In some
cases the package in which a feature symbol would be defined will not
even be defined if the feature is not present.  An example:

   ;; Use fast matrix multiplication if present, else do it by hand
   (defmacro mm (m1 m2 m3)
     #+fastarithmetic:fastarithmetic
      `(fastarithmetic:matrix-multiply ,m1 ,m2 ,m3)
     #-fastarithmetic:fastarithmetic
      `(dotimes (i (array-dimension ,m1 0))
	 (dotimes (j (array-dimension ,m2 1))
	   (let ((sum 0))
	     (dotimes (k (array-dimension ,m1 1))
	       (incf sum (* (aref ,m1 i k) (aref ,m2 k j))))
	     (setf (aref ,m3 i j) sum)))))

A flat namespace for feature names would avoid these problems, and surely
would have no more name conflicts than the existing flat namespaces for
packages and modules.

I'd like to propose that the manual be "clarified" on pp.358-9 to say that
#+ and #- are not sensitive to packages when reading @I[feature]; this
applies both to feature names and to the AND, OR, and NOT operators.
Incidentally, in our implementation feature names can be numbers; these
are not sensitive to radix.  (This is so we can say #+3600; I'd hate for
this to be illegal syntax in another Common Lisp implementation.)
The manual should also be "clarified" on p.448 to say that the symbols
on *features* should be keywords and that any numbers present should
be notated in decimal.  Does anyone object to this?