[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

-- 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>)).