Re: Issue DEFCONSTANT-VALUE

[David N Gray <Gray@DSG.csc.ti.com>]

>   The conclusion we appear to be heading towards is
> that constants must really be constant -- in order to allow the compiler
> to "wire in" values, the value form passed to DEFCONSTANT must always 
> evaluate to EQL values.  In theory, this means that putting something like
> 
>     (defconstant foo '(a b c))
> 
> in a file is wrong, because the value the compiler sees at compile time
> is almost certainly not going to be EQL to the value asssigned to FOO if you
> then immediately load the compiled file!

I wouldn't say that this is wrong; even though the compiler can't in
general wire in the value, that doesn't affect the programmer's intent.
The compiler can take some advantage of the constant declaration, though.
For example, if it sees the form
  (IF (MEMBER 'B FOO) 'YES 'NO)
it could fold this to 'YES since that doesn't depend on EQL-ness of the
list.  Similarly, the form (POSITION X FOO) could be optimized to use some
internal function like POSITION-IN-LIST-EQ since FOO is known to be a list
of symbols.

This has a parallel in conventional languages, where, for example, a named
string constant may end up getting compiled into the same object code as
if it had been declared as a static variable with an initial value, but
the programmer doesn't need to be aware of that.

> I don't know if dealing with cross-compilation issues fall within our
> charter, but a number of the built-in constants like
> SINGLE-FLOAT-EPSILON violate this rule.  The value the cross-compiler
> is allowed to "wire in" to the code is the value for the target
> machine, which may not even be representable on machine where the
> compilation is taking place....

Cross-compilation requires a global target environment which can shadow
the current running global environment, so you could define
SINGLE-FLOAT-EPSILON however you wanted in the target environment.  But
this is beyond what we intend the standard to deal with.