[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: cl-compiler@SAIL.STANFORD.EDU
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: email@example.com (Sandra J Loosemore)
- Date: Mon, 3 Apr 89 17:02:53 MDT
- Cc: common-lisp-object-system@SAIL.STANFORD.EDU
> Date: Mon, 3 Apr 89 17:52 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 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.
Right. In fact, I had such potential conflicts in the back of my mind
when I decided to keep CLOS-MACRO-COMPILATION on hold until we got a
better handle on how to resolve this issue.
> Date: Mon, 3 Apr 89 14:59:57 PDT
> From: Patrick Dussud <firstname.lastname@example.org>
> 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.
The idea behind such a preprocessor is that it would preserve the
semantics of the code it examines. It shouldn't make any assumptions
about types that the compiler itself would not be able to make.
I agree that extending SYNTACTIC-ENVIRONMENT-ACCESS would be a
reasonable solution to the problem. In particular, I remember hearing
suggestions in the past to add TYPE-EXPAND and TYPE-EXPAND-1
functions, that would at least take care of the problems relating to
DEFTYPE. (The interesting thing about DEFTYPE as it relates to this
problem is not determinining whether a type specifier has been defined
with DEFTYPE, but rather what that DEFTYPE expands into.)
I don't think that not having a metaclass for a STANDARD-CLASS object
defined at compile-time is a serious problem. If there's no metaclass
around, that would just indicate that you can't make any assumptions
about the type, the same as if it were not defined at all. (In fact,
I think it would be consistent if DEFCLASS didn't make the
corresponding type specifier defined at compile-time either.)
Is it unreasonable to require that DEFSTRUCT make the metaclass be
defined at compile-time?