Compile Time Class Creation (was: remote environments)

[kempf@Sun.COM]

I've just had time to plough through the X3 mail on CLOS and there was
a point lurking in the correspondence on this topic that I think was
never clearly articulated. That point has to do with the role of
class objects in type checking and inference.

If the goal is to enable compiler implementors and extenders to write
type checking and inference code in an object-oriented way, then some
kind of object representing the class must be created at compile time.
The entire class need not be defined. For example, the slot accessor
method certainly don't need to be defined. 

I think the minimum amount of information which needs to be there is the
following:

	-class precedence list-Because the class precedence list is used
	 in subtyping, it must be available to the type checker.

	-slot location (instance, class)-The compiler might be able to
	 optimize slot access based on this.

	-slot type-Again, potentially necessary for slot access.

	-metaclass-Needed for slot access, possibly to optimize instance
	 creation and initialization.

	-interface information for slot access functions-So they can
	 be optimized.

Most compilers currently use list structures for their type checkers, and
it certainly would be possible to disallow compile time creation of
classes for standard-class objects, to simplify things. But to do so
for the metaobject protocol would limit the metaobject protocol in
a way that would be crippling, since the point of the metaobject protocol
is to allow extensibility in the language processing software. 

There are a number of possible decisions. It could be left either 
unintentionally or deliberately ambiguous. It could be specified that
standard-class objects either are created, are partially created, or
are not created at compile time, while leaving open the question for
other metaclasses (since the MOP will probably not be a part of the
official ANSI Common Lisp '89 standard anyway). However, it is important
to understand the effect of these decisions on future evolution and
user extensibility.

		jak