Re: Issue DEFCONSTANT-VALUE

[David N Gray <Gray@DSG.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.



Issue:	       DEFCONSTANT-NOT-WIRED

References:    CLtL pages 68-69
	       
Related issues: Proposals DEFCONSTANT-VALUE:COMPILE-TIME and
	       COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY

Category:      ADDITION

Edit history:  6 Oct 1988, V1 by David Gray

Problem description:

  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).  

Proposal DEFCONSTANT-NOT-WIRED:NEW-MACRO

  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.

 Examples:

  (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.

 Rationale:

  This provides the functionality desired by those who are reluctant to
  see DEFCONSTANT defined to compute the value at compile time.

 Current practice:
  
  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
  DEFCONSTANT.

 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.

 Benefits:

  Provides a more complete set of options to the user.

 Esthetics:
 
  Complicates the language by adding one more form, but having this as a
  separate feature facilitates giving a clear and simple definition to
  DEFCONSTANT.

Discussion: