[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (version 5)
- To: peck@Sun.COM
- Subject: Issue: DEFPACKAGE (version 5)
- From: Jon L White <firstname.lastname@example.org>
- Date: Fri, 21 Oct 88 19:10:42 PDT
- Cc: CL-Cleanup@Sail.stanford.edu
- In-reply-to: peck@Sun.COM's message of Mon, 17 Oct 88 17:19:14 -0700 <8810180019.AA06479@denali.sun.com>
re: I suggest that the :INTERNAL option be renamed :INTERN.
Hmmm, you've indeed exposed a serious discompatibility in nomenclature
style. But I think I'd prefere to see the :EXPORT option renamed to
be :EXTERNAL rather than introduce a gratuitously new keyword [note
that symbols present in a package must be either :INTERNAL or :EXTERNAL.]
Anyone else on CL-Cleanup have a preference?
re: The rest of the question is whether using the :LISP package is done
in the MAKE-PACKAGE, or lastly, in the (USE-PACKAGE).
If the DEFPACKAGE form doesn't specify a :USE option, then the obvious
thing to do is to default it exactly the same as MAKE-PACKAGE would.
[Incidentally, the name of the relevant issue on this topic is something
like MAKE-PACKAGE-USE-DEFAULT -- PACKAGE-CLUTTER is a separte issue].
re: . . . Like all USE'ing
this should be deferred until after the shadowing is done, no?
Ooops, I guess you're right. Shadowing that creates new symbols isn't
important; but shadowing that in effect "blocks" the inheritance of two
different symbols with the same name must be done before the "using".
So the package should be created with a :use list of NIL, then the
two "shadowings" should be done (if any), then the :IMPORT and :INTERNAL
ones done, and then finally the :EXTERNAL.
re: Clarify that the order of the clauses in the source code has no effect.
Right! good point. Indeed this will have to go in the ultimate version.
re: Also, it says re: side-effects "ie, no IN-PACKAGE is done",
clarify that this does not proscribe an implementation like: ...
I guess the more clear way to say what was intended here is that the
evaluation of a DEFPACKAGE form does not change the value of *package*.
I'll make another version "soon", to incorporate your "nits" and those
of Sandra and myself.
-- JonL --