[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: issue DEFPACKAGE
- From: Jon L White <email@example.com>
- Date: Fri, 21 Oct 88 18:52:57 PDT
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: Sandra J Loosemore's message of Thu, 13 Oct 88 14:34:04 MDT <8810132034.AA19839@defun.utah.edu>
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
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:
(defpackage "PHLOGISTON" (:use "LISP") (:export "FIRE"))
(defpackage "ALCHEMY" (:use "LISP" "PHLOGISTON) (:export "GOLD"))
-- JonL --