Re: issue IN-PACKAGE-FUNCTIONALITY, version 5

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Tue, 24 Jan 89 03:24:57 PST
> From: 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.

The reason why WITHIN-PACKAGE is a macro is because it allows its
special treatment by compile-file to be explained by it expanding into
an EVAL-WHEN, rather than by requiring the compiler to treat it as a
special form.  You yourself have argued that this is how other
compile-time magic (such as DEFMACRO) ought to be explained.

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

Well, what I had in mind was something like

    (defmacro within-package (name)
        `(eval-when (eval compile load)
	     (setq *package*
	           (or (find-package ',name)
		       (error "Package ~s does not exist." ',name)))))

Yes, you're right that the specification is virtually identical to
what the SELECT-ONLY proposal specifies for IN-PACKAGE, except that
WITHIN-PACKAGE is a macro. 

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

Ummm, this is almost exactly what the cl-compiler issue
CONSTANT-COMPILABLE-TYPES says about symbols ("If the symbol is
interned, its name and the name of its home package identify it").  I
seem to remember that you were one of the people who argued *for*
specifying that particular handling of symbols.

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

I think my statement is at least as precise as the language in CLtL it
replaces, which also includes the phrase about "all the symbols in the
file".  If you have some alternative language you would like to propose,
please do so.

-Sandra
-------