issue DEFPACKAGE

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

re: I presume it's the intention of the proposal that the expansion of
    DEFPACKAGE should be wrapped with an (EVAL-WHEN (EVAL COMPILE LOAD)
    ...).  An explicit statement of what you intend for the compiler to do
    with DEFPACKAGE should either appear in this proposal, or be
    communicated to the compiler committee so that we can put it in one of
    our issues. 

This should be covered the "normal" way, like any other defining form, by 
the cl-compiler issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.  I think
it should be implicitly eval-when(eval compile load).

Incidentally, echoing my previous sentiment, it seems simpler and hence
preferable to force the issue on COMPIL-FILE -- simply say that certain
toplevel forms are defaultly eval-when(eval compile load), unless the user 
explicitly wraps some other eval-when around them.  It's far too confusing 
to worry about when COMPILE-FILE retracts definitions that were in effect
"for the duration" of the compilation.  KMP also expressed this sentiment
when replying about the options for DEFCONSTANT-HARD-WIRED (or whatever).



re: I would also like to see more detail on the order that the various things
    are supposed to happen in, in the expansion of the macro.  I'm guessing 
    that it's supposed to be the same as "Put In Seven Extremely Random ..." 
    but I think the description needs to be more explicit.

The proposal does say something about this, and the only time ordering 
dependencies that are important (I think) are:
  (1) the package must be created, with it's :use links all set up, before
      any symbols are placed into it
  (2) most of the symbol creators/importers have to be disjoint, so it
      doesn't matter what order they are performed in.  The exception is
      :EXPORT.  The relevant wording from the proposal is:
	The collection of symbol-name arguments given to the options :SHADOW,
	:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
	disjoint; an error is signalled otherwise.  The :EXPORT option can
	be thought of as occuring after all the other options have been
	executed, since it may reference names found in "used" packages, 
	or found in the argument lists to a :SHADOW, :INTERNAL, :IMPORT-FROM, 
	or :SHADOWING-IMPORT-FROM option.

Perhaps a line or two like (1) and (2) could be added for clarity?


re: Finally, what is the motivation for not having DEFPACKAGE setq *PACKAGE*?

Defining forms usually just establish a name-to-object mapping; there is
little precedent for them also modifying global context state.  The one
form that is currently "confused" this way is the subject of an important
cleanup issue IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY to restore simplicity.

Note that if DEFPACKAGE also did an IN-PACKAGE, then the following 
reasonable file would become somewhat jumbled, because it wouldn't all 
be in on package:
   (in-package "USER")
   (defpackage "PHLOGISTON" (:use "LISP")             (:export "FIRE"))
   (defpackage "ALCHEMY"    (:use "LISP" "PHLOGISTON) (:export "GOLD"))



-- JonL --