Issue: DEFPACKAGE (version 2)

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

    Date: Tue, 17 May 88 02:05:55 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    There is one very dangerous loophole in this proposal, which could be
    trivially plugged up.  The issue is whether symbols are a critical
    arugment to any of the options, or whether "names" would be satisfactory.
    What would you say to the following alterations:

      (1) Change most uses of the meta-variable {symbol} to {name}, with
	  an explicit statement that such a {name} must be either a string,
	  or a symbol.  Thus the description of :IMPORT-FROM would go from 
	    (:IMPORT-FROM {(package-name {symbol}*)}*)
	  to
	    (:IMPORT-FROM {(package-name {name}*)}*)
	  or maybe even
	    (:IMPORT-FROM {(package-name {symbol-name}*)}*)
	  Change also the phrase "Note that only the name of each argument symbol 
	  is used." to something like "Note that only the name of each argument
	  is used; if a symbol is passed, its symbol-name is used".

Saying symbol-name instead of symbol is a reasonable change to the
presentation.

      (2) Flush the two options that require symbols, as opposed to names --
	  namely :IMPORT and :SHADOWING-IMPORT.  Note that these are the only 
	  two that don't have the phrase "Note that only the name of each 
	  argument symbol is used." in their description.  These two options 
	  are superfluous since their functionality is completely covered by 
	  :IMPORT-FROM and :SHADOWING-IMPORT-FROM.

    The :IMPORT option as currently specified makes it all too easy to violate 
    reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without 
    considering the warning given on CLtL p175 (top of page) "... since 
    accessing an internal symbol of some other package is usually a mistake".
    ....
    The disaster that occurs once in a long while is that merely reading in
    FOO::BAR creates some imposter symbol in the BAR package that shouldn't
    be there at all; but the poor loser who does this doesn't find that out
    until a much later time, when a USE-PACKAGE or EXPORT is done.  And of
    course by the time he finds it out, there is little hope of ferreting
    out all the structures already read-in that point to the bogon symbol.

    It may be too much to ask that the :IMPORT-FROM option signal an error
    if no symbol of the requested name is available in the specified package.
    This would (desirably, I think) differ from the reader's action when 
    parsing a double-colon notation.  But at the very least, why add the 
    :IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to 
    names?  Why, when there are perfectly good alternatives that don't have 
    the modularity-violating implications described above?

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, or else :IMPORT-FROM
refuses to create symbols, which as you say ("it may be too much to
ask") is likely to cause problems because things will only work if done
in a certain order so that the symbols get created before they are
needed.  In Symbolics Common Lisp, :IMPORT-FROM will create symbols if
they don't already exist, it's exactly like a double-colon package
prefix.

People who use double-colon-prefix are either confused and asking for
trouble, or know exactly what they're doing.  Either way, your suggested
change to DEFPACKAGE isn't going to help them, as far as I can see.

Thus if people feel that having both :IMPORT and :IMPORT-FROM is redundant,
I'd prefer removing :IMPORT-FROM.  However, I think current practice shows
it's better to have both.  Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?