Re: Issue DEFCONSTANT-VALUE

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Wed, 5 Oct 88  15:37:05 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> Well, let's see.   You've got something like
> 
>   (DEFCONSTANT MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
> 
> and you want the value computed at load time, which means that references
> to MEMORY-SIZE later in the same file will need to be compiled like a
> special variable access.  So you compile the file and load the object, at
> which time MEMORY-SIZE is given a value.  Now, when someone compiles
> another file which uses MEMORY-SIZE, they will be prevented from altering
> it as you wish.  However, since the value is presumably a number, there is
> nothing to prevent the value from being wired in to their compiled code,
> which means that their object file won't work right if loaded on another
> machine with a different amount of memory.  So it doesn't appear that this
> example will work meaningfully with any of the current proposals for
> DEFCONSTANT.

Sigh, you're right.  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 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....

> What you probably want is a new construct midway between DEFCONSTANT and
> DEFPARAMETER which has the feature of preventing run-time alteration, but
> never permits the compiler to wire in the value.

Alternatively, we might either change DEFCONSTANT to not allow the
compiler to "wire in" the values of constants, or change the
definition of DEFPARAMETER to say that it should signal a warning (to
use the new error terminology) if the symbol is rebound or SETQ'd.

In any case, I think this issue is more or less independent of whether or
not DEFCONSTANT evaluates its value form at compile time.  It would be
nice if we could get one coherent proposal that takes care of all the
issues, though.  

-Sandra
-------