[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue DEFCONSTANT-VALUE
- To: email@example.com (Sandra J Loosemore), CL-Compiler@SAIL.Stanford.edu
- Subject: Re: Issue DEFCONSTANT-VALUE
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 6 Oct 88 16:32:05 CDT
- In-reply-to: Msg of Wed, 5 Oct 88 16:37:24 MDT from firstname.lastname@example.org (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> > 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.
Following is a hasty draft of a proposal for a new form in between
DEFPARAMETER and DEFCONSTANT. I'm calling it DEFPARAMETER-UNALTERABLE
here, but don't especially like that name and invite any suggestions for
a better name.
References: CLtL pages 68-69
Related issues: Proposals DEFCONSTANT-VALUE:COMPILE-TIME and
Edit history: 6 Oct 1988, V1 by David Gray
As discussed in issue DEFCONSTANT-VALUE, there are two possible views
of what the purpose of DEFCONSTANT is. Proposal
DEFCONSTANT-VALUE:COMPILE-TIME resolves the controversy in favor of
maximizing opportunities for the compiler to substitute the value for
references to the constant.
There may, however, still be cases where one would like to have the
functionality of prohibiting run-time alteration of a value (like
DEFCONSTANT), but have the value computed at load time and not be
wired in (like DEFPARAMETER).
Add a new macro to the language:
DEFPARAMETER-UNALTERABLE name value [documentation]
which is like DEFPARAMETER except that, like DEFCONSTANT, any further
assignment to or binding of that special variable is an error. Unlike
DEFCONSTANT, the compiler is not licensed to build assumptions about
the value into programs being compiled.
(DEFPARAMETER-UNALTERABLE MEMORY-SIZE (DETERMINE-MEMORY-SIZE))
computes at load-time the value of parameter MEMORY-SIZE, which can
then be used in subsequent initialization to control the allocation of
data structures for an application. Once these structures are
created, changing this parameter would make no sense and might even
break the program. A DEFCONSTANT is not appropriate because the value
needs to be computed at load time and because the value must not be
wired in to any files compiled later or else those object files could
not be used on another machine with a different memory size.
This provides the functionality desired by those who are reluctant to
see DEFCONSTANT defined to compute the value at compile time.
The Explorer has an equivalent capability which is used internally for
various system parameters, since changing them could crash the system,
but the value should not be wired in to object files in order to
maintain object compatibility between software releases.
Cost to Implementors:
This should be easy to add since it is just a different combination of
functionality which is already present for DEFPARAMETER and
Cost to Users:
None, since this is an upward-compatible compatible addition.
Cost of non-adoption:
Continued confusion from the desire to use DEFCONSTANT for situations
that it isn't quite right for.
Performance impact: None.
Provides a more complete set of options to the user.
Complicates the language by adding one more form, but having this as a
separate feature facilitates giving a clear and simple definition to