Issue: DEFPACKAGE (version 2)

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: 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?

I think you must have made this comment before reading the rest of my note
that you are replying to.

re: 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 situation is not quite so simple as that.  I do favor altering the action
of :IMPORT-FROM in the way you deduce, since that would afford a much greater 
measure of package integrity than is now common practice.  However, I 
*strongly* favor removing the requirement for symbols, even if we can't 
agree on the first alteration just mentioned.  The reason why this latter 
semi-proposal affords a difference over doing nothing is two-fold: 

  (1) Certain kinds of non-EVAL file processors may be able to read this 
      form  without evaluating it (cross-reference programs come to mind);
      thus reading in the form with symbols in it  "damages" the ULUZ package
      in a way that "processing" alone would not.

  (2) Many more soure-file/compile-file incompatibilities can easily be
      turned up when the source-file has double-colon qualifications in
      it.  Thus apart from any evaluaton action of the defpackage form,
      there is a possibility that compiled form of the file has different,
      and ocasionlly much worse, side effects than the source file.

For example:

  Source file:

      (DEFPACKAGE  "FOO"  (:IMPORT 'uluz::bunkie))

  Compiled-file: [actions, more or less]

      1. intern DEFPACKAGE in current package [probably inherit from CL]
      2. make string "FOO"
      3. intern BUNKIE in what package????? depends on how that symbol
	 was accessible at compile time.  The fact that the user specified
	 it as uluz::bunkie is completely and totally lost after the source
	 code has been read-in!
      4. intern IMPORT in the keyword package
      5. call EVAL on cons'd-up form


In fact, the original motivation that caused me to start discussing a
defpackage months and months ago was the frequency at which "vanilla"
code can be read-in differently after being compiled [differently, because
of the information-losing property of double-colon format].  So even if
:IMPORT-FROM were to continue in its present (Symbolics) semantics, it would
still be of some benefit to use strings as args rather than symbols, in order
to prevent the occurance of obscure source/compiled-file differences.


-- JonL --