[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What package are feature names resident in?
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 . . .
Some folks here at Lucid think there was discussion on the matter a couple
years ago, but no one seems sure if a resolution was achieved. Any
commets?
-- JonL --
P.S. The problem isnt IN-PACKAGE -- as someone pointed out already, it
is so trivial as to be almost redundant. Most usages of it would be
equivalent to (setq *package* (find-package <package-name>)).