[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
- Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 3 Apr 89 17:52 EDT
- Cc: cl-compiler@SAIL.STANFORD.EDU, common-lisp-object-system@SAIL.STANFORD.EDU
- In-reply-to: <8904032121.AA18470@defun.utah.edu>
What do the rest of you think about this?
I think you're pointing in the right direction, however there is a
problem. Any specification in terms of the metaclass requires that
class objects be created at compile time by COMPILE-FILE, or there
is no reasonable way to find out at compile time what the metaclass
is. CLOS-MACRO-COMPILATION (which you wrote) seems to be trying to
avoid requiring any compile-time objects to be created. So we have
a conflict between two proposals. In fact it's possible that the
metaclass is the wrong way to say "this class will not be redefined
later" and instead that should be said by the way that the program
is compiled, not by anything in the program, making it an environment
issue rather than a language issue.
An interesting question is whether this type-inferencing preprocessor
is supposed to be able to accept all conforming programs, or only
a subset of conforming programs subject to additional restrictions,
for example that class definitions in the program are not changed
between preprocess time and run time. Saying that we have two languages,
the full language and the type-inferencing preprocessable subset,
might eliminate the conflict here (although it will likely make
Gabriel sound off).