[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: cl-compiler@sail.stanford.edu
- Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 27 Feb 89 09:51:57 MST
- Cc: common-lisp-object-system@sail.stanford.edu
I have a new version of this proposal in the works. I've consulted
with Kathy Chapman on how to handle the wording problems that were
brought up earlier. But, there is still the paragraph that deals with
CLOS that some people indicated there were problems with.
This is the way it reads now:
(h) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
Would anyone like to suggest some alternate wording?
A problem with the existing language that occurs to me is that the
previous paragraph of the proposal says that type specifiers
introduced with DEFTYPE or DEFCLASS must be defined the same at
runtime as at compiletime. The idea is that, if the compiler is
allowed to "wire in" type information (by making use of declarations,
for example), those types have to fit into the type hierarchy in the
same way at runtime as at compiletime. To me it seems like these same
considerations must also apply to types introduced by DEFCLASS,
regardless of the metaclass involved.
-Sandra
-------