[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (version 2)
- To: Moon@stony-brook.scrc.symbolics.com
- Subject: Issue: DEFPACKAGE (version 2)
- From: Jon L White <firstname.lastname@example.org>
- Date: Sat, 21 May 88 05:13:49 PDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: David A. Moon's message of Fri, 20 May 88 22:12 EDT <19880521021246.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: Well, wait a minute. Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, . . .
That isn't quite right. :IMPORT explicitly requires you to put symbols
in the source code, and it is the reading in of that code (with its
liklihood of having bogon-producing :: syntax) that causes the lossage.
For example, if your file had in it:
(defpackage my-package (:import 'uluz::bunkie))
then the damage to the ULUZ package is done by the reader long before
defpackage or :import ever has a chance to muck things up.
I suggest removing :IMPORT because the :IMPORT-FROM format can be made
to work given only the symbol-name (not the symbol itself, with it's home
package known); there would be no other way to indicate the package
information for :IMPORT if you used only symbol-names as arguments.
Oddly enough, looking back over the mail on this issue, it seems as though
KMP wanted to suggest exactly the same thing, in a messaged dated
Sat, 12 Mar 88 19:14 EST. Your disagreement with him was phrased as
I disagree because of alphabetic case issues in strings. Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues. . . .
but this argument fails to account for the fact that the damage is done
by the reader, when it is required to read in symbols, rather than by
any action of defpackage itself.
re: Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?
Well, only in that it not create an entry *** in some other package *** where
one doesn't already exist; I wouldn't necessarily want it to require the
symbol to be external. Yes, I think it would be a tremendous step forward
in helping to prevent one of the most obscure nits that even an experienced
package user can fall into.
-- JonL --