[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue DEFCONSTANT-VALUE
- To: Jon L White <jonl@lucid.com>
- Subject: Re: Issue DEFCONSTANT-VALUE
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Wed, 5 Oct 88 15:58:01 CDT
- Cc: CL-Compiler@SAIL.Stanford.edu
- In-reply-to: Msg of Sat, 1 Oct 88 16:52:06 PDT from Jon L White <jonl@lucid.com>
- Sender: GRAY@Kelvin.csc.ti.com
> But the second part of your proposal, while laudable in my
> opinion, is not at all what Lucid does:
> . . . The value form
> will be evaluated at compile-time, with the resulting value being
> used to SETQ the symbol at load time, ...
> Several other vendors I've looked at seem to do no constant folding
> whatsoever; Lucid does some constant folding, but gives absolutely
> no guarantee just what things will be folded and under what
> circumstances. For constants that are not "folded", the SETQ
> performed at runtime does a completely fresh re-calculation at
> load-time.
I agree that this part is not as clear-cut and I don't have strong
feelings about it. Since my implementation does do extensive constant
folding, it seemed that consistency would be maximized by ensuring that
the constant didn't end up with a value different from what was wired in
to the code in the same file. Maybe we should just leave this unspecified
in accordance with proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY, which
says:
Except as noted, the behavior of user programs is unspecified in
situations where the information is defined differently at runtime than
at compiletime, since the user cannot depend upon which will take
precedence in a particular implementation.
In other words, if the value is the same either way, then it doesn't
matter, and if there is a difference, then that is an error.