[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packages & Compiling
- To: firstname.lastname@example.org
- Subject: Re: Packages & Compiling
- From: Timothy.Freeman@theory.cs.cmu.edu
- Date: Mon, 12 Jan 1987 23:15:00 -0000
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: <870112151228.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 12 Jan 87 15:12 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
It's also true that if the value of *read-base* is different when you do
the compilation, or if the read table has been altered in any way, all
bets are off. In other words, the phenomenon is not specific to
packages, but applies to any state information that affects the actions
of the Lisp reader. The compiler has to be careful to do its reading
with all the parameters set appropriately.
I don't have any problem with the values of a couple of special
variables affecting the behavior of the compiler for two reasons.
(This is not a statement about whether these dependencies should
exist; I'm just trying to say that they are less troublesome.)
If I start having problems with these variables having the wrong
value, I can always write a little function or macro that sets or
binds them to standard values.
I don't change the values I use for these variables often, so the
problem never really arises.
The dependency of the behavior of the compiler upon the package
environment does give me problems for the same two reasons:
It is normal for the code that is being compiled to change the
package environment, so there is no standard value for the package
I do change the package environment often, so this is a real
In general, the compilation process should not depend upon aspects of
the current environment which are not easy to change, unless that
dependency allows better code to be produced. Allowing the compiler
to depend upon the package environment when it is compiling a
not-in-line function call doesn't allow it to produce better code.