Issue: DEFPACKAGE (version 2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Sat, 21 May 88 05:13:49 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    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.

None of this addresses my comment.  If the user insists on referencing a
non-exported symbol of the ULUZ package, what is the difference between
referencing (and hence creating) that symbol while reading an argument
to the :IMPORT option, and referencing (and hence creating) that symbol
while obeying the :IMPORT-FROM option?

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

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

Oh, yes, I had forgotten the argument for allowing symbols as arguments
when strings would do, so people can write their code in lower case
even though Common Lisp is an upper case language.  Good point.

    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.

See above.

    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.

Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that
single-colon uses.  I wish you had come right out and said so.
The problem I see with this is that if the user hasn't already done
something to create the symbol, he gets an error.  Thus the problem
we were trying to address with DEFPACKAGE, of having to load everything
in a certain order or it doesn't work, wouldn't be completely solved.
It might be worth it.

Then again, maybe this whole problem is a non-problem.  Maybe anybody
who uses the double-colon package prefix is just asking to lose and
nothing we do can change that.