[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Packages & Compiling
- To: navajo!Timothy.Freemanfirstname.lastname@example.org
- Subject: Packages & Compiling
- From: email@example.com (Jon L White)
- Date: Thu, 15 Jan 87 01:17:39 PST
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: Timothy.Freeman@theory.cs.cmu.edu's message of Sunday, 11 January 1987 22:22:19 EST
The quotation you attribute to me is a little bit out of context in that
". . . requirement that the package world be EXACTLY the same at
load time that it was at compile time."
wasn't meant to imply that you will be guaranteed to lose when that
"requirement" is violated -- only that you can't be guaranteed to win.
In particular, lots of trivial such violations occur all the time, with
The kind of lossage you and Tom Gross had experienced may have been
caused by a different set of using packages between the compilation
environment and the load time environment. At any rate, such a
difference (in the package-use-list of your application package) may
or may not cause trouble -- depends upon whether your compiled file
uses any of the symbols that were accessible via inheritance from the
package that was "used" at compile time but missing at load time, or
has any symbols which are expected to be created in the application
package but which are spuriously inherited from a used package that
wasn't also used at compile time.
There are other possible problems too, but they are not all related to
compilation. For example, it is not at all difficult to cook up a
little test file that will "act differently" when merely loaded in
interpretively two times in a row. But of course, loading a compiled
file compounds the number of cases in which you may lose because,
typicaly, the compiled-file "reader" is not at all the same as READ.
In general, however, you are touching on the issue of insulating the
compilation environment from *any* side-effects occuring in the lisp
before the file compilation in question, including those caused by
previous compilations. You specifically bring up only the issue of
compiling a file twice, and seeing a different package environment the
second time. But the potential for lossage is much more complex than
merely package side effects; for example, think of macro definitions --
do you want them visible or not? maybe sometimes "yes" and sometimes "no".
There was a paper in the 1986 Lisp Conference on an "Un-Common Lisp"
that mentioned one partial solution the the issue. There is also an
ANSI sub-committee addressing the issue of compilation semantics -- perhaps
they will attempt to define just how much insulation you can expect. Quite
possibly, they should address the semantics of just how the compiled file
reader can differ from READ.
-- JonL --