[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remote environments
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: remote environments
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Fri, 10 Mar 89 16:49:44 CST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Msg of Mon, 6 Mar 89 21:37 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.csc.ti.com
> I think it would be much nicer if we could make compile-time classes
> instantiable. However, I agree that it would not ruin the language to
> omit that feature if we can't figure out how to do it.
I agree that it would be nice, and intend to support it in our
implementation (it's already implemented but has a few problems to be
worked out). It's just a question of whether it can be specified in a
way that everyone can live with.
> - If so, do initforms have access to macros and constants defined
> earlier in the file?
>
> Initforms certainly have access to those things since they are included
> in the initforms' environment. I think 88-002R implies this.
I intend to implement it that way since it is a reasonable thing to
expect. However, I'm not aware of any language in 88-002R that requires
this ("implies" isn't good enough). In fact, proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS explicitly says that macro
definitions are _not_ necessarily available to the evaluator during
compile-time evaluations.
> I think that the standard could take a simple, minimal, approach that
> would still satisfy the most common usages. Suppose we said:
>
> DEFCLASS
...
> One way to look at this would be to
> say that it is implementation-dependent whether FINALIZE-INHERITANCE
> works or signals an error when given a class defined in the
> compile-time environment.
>
> [And no compile-time generic-function or method objects at all]
>
> This is an interesting idea, but I think it's too restrictive. Here's a
> plausible and many-times proposed application for metaobjects which
> would not be possible if we adopted this idea. Suppose you made an
> optimizing compiler that is allowed to assume that no class
> redefinitions, no method redefinitions, and no newly-defined subclasses
> will be created at run time. The compiler is to take advantage of this
...
I certainly don't want to prevent any implementation from doing that.
The real issue is what is the minimal functionality that all
implementations must support.