[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- To: Jeff Dalton <email@example.com>
- Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Tue, 20 Sep 88 10:25:59 MDT
- Cc: sandra <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Tue, 20 Sep 88 16:19:42 BST
> Date: Tue, 20 Sep 88 16:19:42 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> I am less hapy with the exception that allows the interpreter to
> multiply evaluate the expression to produce a new value each time.
This argument would bear a lot more weight with me if you could
suggest some implementation technique that guarantees only a single
evaluation in the interpreter that doesn't require the intepreter to
perform a preprocessing code walk, and still provides reasonable
semantics. I thought about this for a long time and was unable to
come up with any other way to implement the semantics in KMP's
proposal. I think it is unreasonable to force implementations that
don't use a preprocessor to rewrite their interpreter just to support
this new special form.
> While the exception is consistent with the rules for macros, I
> do not think the two cases are really analogous. LOAD-TIME-VALUE
> results in an object, so it matters if the object is a different
> one each time.
Macros can construct and return (quoted) objects as well. I don't
think that allowing multiple evaluations of LOAD-TIME-VALUE is really
all that much more confusing than allowing macros to be expanded more
> I suspect it will be a pain to write code that can take advantage
> of the COMPILE-FILE guarantee but nonetheless still work if the
> form is multiply evaluated.
I agree, this is something that is likely to confuse users, but it's the
best I could come up with. If you can suggest some other compromise
that will accomodate both destructive operations and those implementations
that don't use a preprocessor in the interpreter, by all means do so.
> > If a LOAD-TIME-VALUE expression appears within a function compiled
> > with COMPILE, the compiler may either evaluate the <form> or use
> > a previously cached value.
> I'm not sure what this means. Does it mean that different code
> compiled at different times can nonetheless end up using the same
> value? (I hope not....)
No, what it means is that if you compile an interpreted function that
has already gone through some preprocessing to evaluate a LOAD-TIME-VALUE
expression in the body, the compiler can reuse that value instead of
having to reconstruct the source code and evaluate it again. The
wording should probably be more specific about this.