Issue: DEFPACKAGE (version 2)

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

  (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".
Much worse, I've seen even very experienced hackers (more than 10 years
experience) fall into the trap of thinking that FOO::BAR means "access
the internal symbol BAR in the FOO package", or "access the symbol BAR
present in the FOO package, regardless of whether it is external or not".
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?


If these two alterations are made, then a DEFPACKAGE can be written with
all data specified as strings; and in the cases when symbols are actually
are supplied, then the compiler can convert them to strings as they are
put out into the fasl file. (Essentially the same compiler conversion
takes place now in Symbolics treatment of SHADOW, and in Lucid's 3.0
release version of SHADOW).



-- JonL --