A-Packaging we will go...

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

    Date: Fri, 12 Apr 85 10:00:19 EST
    From: greek@DEC-HUDSON

    [My new comments are in square brackets -- Paul.]

	Well, Mr. Moon, I gave your comment some thought.  It was a bit terse,
	but perhaps this is what you meant:

	What happens if a macro calls a function during the expansion of a
	macro call?  If that function is in, say, the "USER" package, and the
	compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
	THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
	at compile time.

    What if the function was in the LISP package?  Does your special compiler
    package inherit from there or doesn't it?  If it doesn't, macros can't
    run.  If it does, you can't tell whether a symbol came from there via
    package prefix or via inheritance.

    [Well, as you say, it must inherit from the LISP package.
    But why do I care whether the compiler can tell that the symbol had
    a package prefix or inherited the symbol?  The fact is that the symbol
    is in the LISP package, so the fast loader better find it there.]

I thought the whole point of your suggestion for a special compiler package
was that you cared.

	But then again, it wouldn't be found if the user didn't happen to be
	in the "USER" package when compiling the program.  If the program
	must be compiled in the "USER" package, it ought to do an IN-PACKAGE
	at the top.

	If I read you wrong, please let me know.

	By the way, here's what VAX LISP currently does:  If the compiler goes
	to dump a symbol which is in the current package (not any special
	compiler package), then it dumps it without a package.  This means
	it will be loaded into the current package at the time of loading.

    In other words, it does the same thing as PRINT.  This is what our compiler
    does, too.

    [But do we agree that's correct?]

I believe that it is inherently the best thing that can be done, if you grant
the compiler uses the Lisp READ function as its lexical analyzer.

	I don't think this is quite right, since it means that if I'm in
	the "FOO" package when I compile, and I say FOO::SYM, and then I'm
	in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
	To avoid this problem, I think you need the special compiler package.

    A better approach is for the compiler to tell the loader what the value
    of *PACKAGE* was when the file was compiled.  If the loader binds
    *PACKAGE* to the same value (that is, to a package with the same name)
    when the file is loaded, symbol names in the compiled file will be
    interpreted as the compiler intended when it dumped them.  This approach
    works well for us.  Of course the user can get into arbitrary amounts of
    trouble by changing package definitions between the time a file is compiled
    and the time it is loaded, but that is inherently unavoidable.  For instance,
    if the source file referenced FOO::SYM, and SYM was imported or inherited
    by the source file's package at compile time, but not at load time, then
    the wrong SYM will be referenced.

    [I don't see how this solves the problem I described above with the FOO
    and BAR packages.  Seems to me that SYM would end up in the FOO package
    alright, but so would an unqualified symbol, say SYM2.  But SYM2 ought
    to end up in BAR, the current package at load time.  To summarize:

    source file, compiled when FOO is current package:

	    FOO::SYM1
	    SYM2

    fastload file, loaded when BAR is current package:

	    FOO::SYM1	; Better end up in FOO.
	    SYM2		; Better end up in BAR.
    ]

This problem derives entirely from the (doomed) attempt to compile a file
in one package and load it into another.  You cannot expect reasonable
results from this.  Hence my suggestion for the loader to ensure that the
file is loaded into the correct package.  If FOO was not the correct
package, why did you compile it in that package?  Or, to ask the question
another way, why did your compiler compile it in the wrong package?  This
relates to the other discussion about the file attribute convention (-*-).

This piece of mail is getting rather long.  I suggest that if we need to
discuss this further, we should prune it.  I myself don't have anything
further to say.