issue COMPILE-ENVIRONMENT-CONSISTENCY

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

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).  

Having had time to think about this for a while, to me it seems like
this amendment is going to cause trouble.  I've been thinking about
our canonical example of a type-inferencing preprocessor.  Such a
preprocessor could conceivably be written so as not make use of
information about certain type relationships, provided that it is
possible to test whether a type specifier is one of the ones that it
can't make assumptions about.  That's the real problem: given a type
specifier, how do you know whether it was defined with DEFTYPE or
DEFSTRUCT, or some other way?

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?

-Sandra
-------