-*- Mode:Text; Base:10 -*-

		   SIMULATED COMPILATION ENVIRONMENTS


  The regular Lambda compiler now supports a new type of structure,
the COMPILER:COMPILATION-ENVIRONMENT.  It is implemented as a defstruct
with internal hash tables for slots; in these hash tables, new
definitions brought into existence as part of a given compilation can be
stored as distinct from the running environment of the compiling
machine.

  For instance, suppose the Lambda and K environments require the
MULTIPLE-VALUE-BIND macro to expand differently.  Two separate DEFMACRO
definitions can be prepended with "#+" reader macros in the relevant
source file.  However, when cross compiling (say, from a source Lambda
to a target Falcon) it is not feasible to redefine the Lambda's
MULTIPLE-VALUE-BIND, because of the global ramifications such a
redefinition would surely have on future native compilations.  Under the
new scheme, when doing a file compilation, the compiler stores
definitions of macros, symbols, substs, type definitions, etc. inside a
COMPILER:COMPILATION-ENVIRONMENT structure created specifically for the
compilation, at its inception.  It is discarded after the compilation.

  This mechanism is not new.  The existing Lambda compiler maintains
several association lists during a file compilation which carry the same
data.  The new mechanism, however, is more efficient, and makes the
long-term storage of the relevant definitions possible.

  The CROSS-COMPILE-FOR-K cross compiler produces two output files.  The
Falcon compiled code file has the standard extension "FBIN".  In addition, a `K
Environment' file is also created with the standard extension "FENV".  It is a
QFASL-format file that contains all the file-local definitions accumulated in
the compilation-environment file.  When it is subsequently loaded into a world
the definitions will be added to the COMPILATION-ENVIRONMENT structure in
COMPILER:*COMPILATION-ENVIRONMENT*.  Loading a FENV file into a cross-compiling
Lambda world is analogous to loading the compiled FBIN into the Falcon world,
were compilation being done natively.  In other words, loading a FENV file into
the Lambda makes available to the cross compiler the macro and constant
definitions in a previously-compiled file.

  To make this work, COMPILATION-ENVIRONMENT structures are actually nested.
Each one has a NEXT field, which is either NIL or some other
COMPILATION-ENVIRONMENT from which it inherits additional definitions.  The
COMPILATION-ENVIRONMENT created for a COMPILE-FILE is automatically nested
inside the current binding of COMPILER:*COMPILATION-ENVIRONMENT*.  This
simulates the inheritance of the definitions in compiled files previously loaded
into the world.

  This mechanism happens automatically, so developers probably won't have to
worry about it very much.  Nesting of environments can occur to any depth, but
it is doubtful whether there will ever be any use for more than two levels.
However, COMPILE-FILE and QC-FILE now accept an explicit keyword
EXPLICIT-COMPILATION-ENVIRONMENT argument in case the MAKE-SYSTEM facility finds
use for more control.

  The following are the developer-visible functions which support cross
compilation.

	COMPILE-FILE-FOR-FALCON  filename			Function
	  This function behaves similarly to COMPILE-FILE, except in that
	  it invokes the cross compiler instead, after binding
	  *COMPILATION-ENVIRONMENT* to the value stored in
	  COMPILER:*FALCON-ENVIRONMENT*.  The version numbers of the
	  FBIN and FDEF files will be the same as the source file, just
	  as is done for QFASL files.

	COMPILER:*FALCON-ENVIRONMENT*				Variable
	  This variable  holds a COMPILATION-ENVIRONMENT structure, which
	  accumulates definitions from all the FDEF files that have been
	  loaded since the last time the machine was cold-booted.


	LOAD-FALCON-DEFINITIONS  filename			Function
	  This function behaves similarly to LOAD, except in that it
	  defaults the pathname type to FDEF, and binds
	  *COMPILATION-ENVIRONMENT* to the value in
	  COMPILER:*FALCON-ENVIRONMENT*.