[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: DEFPACKAGE (version 2)

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