[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What package are feature names resident in?
- To: Common-Lisp@SU-AI.ARPA
- Subject: What package are feature names resident in?
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Thu, 13 Jun 85 22:42 EDT
- In-reply-to: The message of 25 Apr 85 07:19-EST from Jon White <JLW@SU-AI.ARPA>, <RAM.12106292554.BABYL@CMU-CS-C.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:
(push 'dull *features*)
(push 'snazzy *features*)
'(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
because you don't which symbol the "Lispm" will turn into. Should you
have to say
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:matrix-multiply ,m1 ,m2 ,m3)
`(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?