[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue IN-PACKAGE-FUNCTIONALITY
- To: cperdue@Sun.COM
- Subject: issue IN-PACKAGE-FUNCTIONALITY
- From: Jon L White <jonl@lucid.com>
- Date: Sat, 10 Dec 88 01:33:40 PST
- Cc: cl-cleanup@sail.stanford.edu, cl-compiler@sail.stanford.edu
- In-reply-to: Cris Perdue's message of Wed, 7 Dec 88 11:00:24 PST <8812071900.AA05045@clam.sun.com>
re: Remember that even the strictures in CLtL are awkward: it is admitted
up front that package effectors "should appear only at top level within
a file" (p182).
That quote is out of context. The paragraph on p.182 makes it clear
that it is talking about the creation of the package "in" which the
file is to be read; and it only says that to guarantee proper
compilation of a file **** in all Common Lisp implementations ****
these functions should appear at top level. There certainly is no
advice, let alone any constraint, against calling these functions from
interior levels when they bash unrelated packages.
re: To me, if there is going to be DEFPACKAGE, it is better to just
acknowledge the problems that exist when compiling files with
compile-time calls to package effectors rather than retaining the
current hack half-solution.
I'm afraid I haven't the foggiest idea what you are talking about here.
Sandra seems to think you mean the special compile-time wrapping of the
"7 Extremely Randoms" -- is that all? Regardless of that question,
the need to serialize the computations found in a Lisp file is not
affected by whether DEFPACKAGE is one top-level form or "7 random"
top-level forms. It's Lisp's view of what LOADing a file means.
-- Jonl --