issue IN-PACKAGE-FUNCTIONALITY, version 5

[Jon L White <jonl@lucid.com>]

I don't see the new macro name solving any fundamental problem that is
worth a tremendous incompatible change.  In fact, it doesn't even solve
the specification problem, since you would now have to remove the lines
that talked about special treatment (read: evaluation when found at
top-level of compile-file) and add virtually identical lines specifying 
what the macro expansion of WITHIN-PACKAGE does.

Beyond that, there are some sections that I have problems with:


re:     This macro causes *PACKAGE* to be set to the package named NAME,

When?  At macro expansion time?  or do you mean it is a trivial
expansion into (setq *package* ...)?


re:  . . . Everything this macro does is also
    performed at compile time if the call appears at top-level.

Oh really?  Then structurally, the specification is identical to IN-PACKAGE?


re:     When a compiled file is loaded, the symbols it contains are interned
	in the same package they occupied when the file was compiled.  

I think I read this as yet another attempt to resurrect the very misleading
plan of compiling symbols out by package-qualifying each and every one of
them.  Think about making this requirement on PRINT.  Under this rule, it 
would be hopeless for a source file and compiled file to "do the same thing",
since the original source had most symbols unqualified, and the "processed"
version had all symbols qualified.  Thus in later loadings, the original
source would simply "float" to wherever the current inheritance of symbols
came from; but the "dumped" version would (incompatibly) require them to be 
in specific packages.   This is too long an issue to debate over the mails, 
but I wonder how many readers have themselves gone through the enlightening 
phase of trying out "qualify all symbols" and finding the flaws in it?


re:     A  necessary condition for a program contained in a file to be a
	conforming Common Lisp program is that, when the source file is
	processed by COMPILE-FILE, all of the symbols in the file be interned
	in the same package they would occupy if the source file were
	loaded directly with LOAD.

Conforming to what?  This statement is incredibly imprecise, since the
packagification of symbols depends on more than simply the text of the
file.  For example, what do you mean by "all of the symbols in the
file"?  Suppose I have a macro that does something like
   (foo x)    ==>  (internal-subr (list x))
and suppose further I have a file with just the one form (foo 3) in it.
Now, is FOO a symbol in the file?  Is INTERNAL-SUBR a symbol in the file?
and what guarantee is there that FOO expands the same way when "in the
compiler" as when running interpretively?  [many implementations do
provide a way to find out kludgily whether or not you are "in the
compiler"].



-- JonL --