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

			Background for Proposal:

	      Lambda System Source Code Conditionalization

				 for the

			    Falcon Processor

------------------------------------------------------------------------

			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
automatic file-compiling facilities (such as MAKE-SYSTEM) find 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 the symbol
	  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 the variable
	  *COMPILATION-ENVIRONMENT* to the value stored in the symbol
	  COMPILER:*FALCON-ENVIRONMENT*.