issue COMPILE-ENVIRONMENT-CONSISTENCY

[Patrick Dussud <dussud@lucid.com>]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Mon, 3 Apr 89 15:21:11 MDT

   At the meeting, an amendment was proposed to this issue to replace all of
   the current item (g) with:

     The compiler can assume that type definitions made with DEFTYPE or
     DEFSTRUCT in the compiletime environment will retain the same
     definition in the runtime environment.  This implies that
     subtype/supertype relationships of type specifiers defined by DEFTYPE
     or DEFSTRUCT will not change between compiletime and runtime.  (Note
     that it is not an error for an unknown type to appear in a declaration
     at compiletime, although it is reasonable for the compiler to emit a
     warning in such a case.)

   The proposal was tabled with this amendment pending (it was not
   officially seconded or voted on).  

   Also, one might want to define a metaclass that does license the
   compiler to make assumptions about the type hierarchy of its instance
   classes not changing.  (In fact, I think this would be a rather common
   extension.)

   I wouldn't object to rewording the amendment so that the compiler is
   permitted to make assumptions about all type specifiers except those
   that name classes whose metaclass is (a subclass of) STANDARD-CLASS.
   It's at least possible (although a little convoluted) to test for that.

   What do the rest of you think about this?

When we drafted the amendment, I was thinking of specifying the behavior of
conforming programs. Precisely, I think that it provides an answer to the
following question:
 What kinds of consistency should the programmer preserve, from compile-file
to load? with the understanding that these constraints of consistency are
dictated by the compiler.
What we are proposing, is that in the general case, the user is free to
redefine the class between compile-file and load. 

In this sense, the situation you describe has little bearing. I your case, the
kind of consistency that the programmer has to maintain is dictated by the
metaclass, not by the compiler. If compile-file can take advantage of this
restriction, fine. I don't think that an implementation doing just that would
violate the proposal as amended.


Your first question about type-inference preprocessor touches more on
compile-time meta-object creation, or syntatic-environment access. I
understand the problem, I don't know what is the best solution. I personally
lean towards extending the syntactic environment access, because we don't want
to specify that metaobject should be instantiated at compile time.

Patrick.