[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: Patrick Dussud <email@example.com>
- Date: Mon, 3 Apr 89 14:59:57 PDT
- Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: Sandra J Loosemore's message of Mon, 3 Apr 89 15:21:11 MDT <8904032121.AA18470@defun.utah.edu>
From: firstname.lastname@example.org (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
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
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.