[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue IN-PACKAGE-FUNCTIONALITY
- To: cperdue@Sun.COM, firstname.lastname@example.org
- Subject: Re: issue IN-PACKAGE-FUNCTIONALITY
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Wed, 7 Dec 88 11:00:24 PST
- Cc: email@example.com, firstname.lastname@example.org
> re: It would be quite nice if the ANSI standard could do without the
> current requirement that LOAD must interleave resolution of symbol
> references and execution of top level forms. (p.182) . . .
> My impression is that it would be within reason to eliminate this
> requirement if we adopt DEFPACKAGE. Has that been considered?
> No. The DEFPACKAGE proposal would have no bearing on this, . . .
Well, one could eliminate the requirement for implementations to do
this based on the rationale that the strongest motivation is now gone.
The reasoning is some kind of cousin to the reasoning that says
implementations need not treat most package effectors as if wrapped
in (EVAL-WHEN (COMPILE ... ) ... ).
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). It isn't *possible* to accomplish the stated objective
(" ... when a compiled file is loaded, all of the symbols in the file
end up in the same packages that they would occupy if the Lisp source
file were loaded.") -- because READ loses information.
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.