Compile-file environment

[Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>]

In order to compile in advance (compile-file time ) some implementation
aspects of CLOS metaobjects, there must be some clos metaobjects
residing in an implementation dependent environment, that do not visibly
side effect the runtime environment.  The visible entry points to this
environment come from name to object mapping (FIND-CLASS and
ENSURE-GENERIC-FUNCTION).  I propose that a runtime environment CLOS
object cannot visibly point to a compile-file environment object(No
visible cross environment links).  I think that makes metaclass
programming a lot easier.

Environment Capture
When compiling CLOS DEF..  forms, a evaluation must take place that
affects the compile-file environment, and this evaluation must be a
similar to what happens when the forms are evaluated. 
I propose that the standard expansion of the DEF... macro be:

(defclass foo () ())
 =>
(eval-when (load eval compile)
  (add-named-class (class-prototype (find-class "STANDARD-CLASS"
                                                (name-environment env)))
	                 :name 'foo
                         :environment (name-environment env)))

Where name-environment take the value of a macroexpand environment and
returns the right environment for the right situation.  The value
returned by name-environment can be passed as the environment argument
to all CLOS functions that accept and environment argument.

Presumably, when evaluated in the EVAL and COMPILE-TO-CORE situation,
this name-environment returns NIL (the runtime environment).  When
evaluated in the COMPILE-FILE environment, it returns the compile-file
environment.  When evaluated in LOAD situation, it returns the runtime
environment.  Since the compiler and the evaluator have to treat this
function differently, Logically, this is a special form.


Environments behavior
The compiler should be responsible for implementing the inheritance and
shadowing  of objects in different environments.  However, find-class
should not return a runtime object when the environment argument points
to a compile-file environment.  This avoids cross references across
environments.  I don't think this is a good idea for FIND-CLASS to
return a created class object when an inheritance has to happen.  I
think that should be explicitly done by calling MAKE-DEFAULT-METAOBJECT.

MAKE-DEFAULT-METAOBJECT metaobject-prototype name &optional environment.  Generic-function

The default method on standard-class returns
a forwarded-class when the environment is a runtime environment, and
does the implementation dependent environment inheritance or
forwarded-class creation if the environment is a compile-file
environment. 

Inside of ADD-NAMED-CLASS, MAKE-DEFAULT-METAOBJECT is called when (find-class
class-name nil environment) returns NIL.

Inside of ADD-NAMED-METHOD (or something like that), during the
normalization of the specializers,MAKE-DEFAULT-METAOBJECT needs to be
called if (find-class class-name nil environment) returns NIL when the
environment is a compile-file environment.

Inside of ENSURE-GENERIC-FUNCTION, we need to have the same mechanism.
Either we extend FBOUNDP to accept an environment argument, or we come
up with an equivalent of FIND-CLASS, does not matter much.

MAKE-DEFAULT-METAOBJECT is specialized on standard-generic-function and
returns the appropriate generic function object.

Patrick.