[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Mon, 3 Apr 89 15:21:11 MDT
- Cc: email@example.com
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
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?