On Fri, Feb 09, 2001 at 09:59:27AM +0100, Raymond Wiker wrote:
> kr@... writes:
> > > But the low-level facilities aren't present in the
> > > cross-compilation host, so reading fasl files which are intended to
> > > work in the target is rather problematic.
> > ok, that makes sense.
> > so to really make sure that i understand: is the problem with
> > cross-compilation that things like constants and defmacros need to
> > persist across multiple files ?
Yes, this is the problem that I was writing about.
Note that in SBCL there's also some stuff which macro expanders
calculate and store in ordinary variables, not in the compiler's
environment. One example is *SYSTEM-CONSTANT-CODES*. If you want to
design a way to keep compilation side effects cleanly local to the
compilation environment in a macro-heavy side-effectful language like
Common Lisp, it would probably be a good idea to provide facilities to
allow application programmers to store stuff like
*SYSTEM-CONSTANT-CODES* somewhere local to the compilation
> > what one of course really would like is a compilation environment
> > that lets one compile a whole application consisting of several files,
> > after all of which the (temporary) changes to the image disappear.
> Would it be possible to do compilations in a separate
> environment, whcih would be discarded after the compilation? The
> problem with compiling several files in one operation could be handled
> by wrapping the compile in a with-compilation-unit (I guess :-)
Yes, I think that's right: if SBCL were rewritten to try to keep
compilation side effects cleanly isolated in a compilation
environment, then you could probably still make everything work at
cross-compilation time by using WITH-COMPILATION-UNIT to cause
everything to be done in a single compilation environment.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C