Issue DEFCONSTANT-VALUE

[Jon L White <jonl@lucid.com>]

re: Proposal DEFCONSTANT-VALUE:COMPILE-TIME:
    . . . 
    DEFCONSTANT: The compiler must recognize the symbol as being constant
    (for example, to suppress warnings about references to the symbolic
    constant as an unbound variable or to enable warnings about binding or
    SETQ'ing the constant in the code being compiled).  The value form
    will be evaluated at compile-time, with the resulting value being used
    to SETQ the symbol at load time, and being available for the compiler
    to substitute in when compiling references to the constant name (as
    described on pages 68-69 of CLtL) and when evaluating the value forms of
    subsequent DEFCONSTANTs.  It is implementation dependent whether or
    not the symbol value is actually set at compile time or whether
    COMPILE-FILE temporarily remembers the value in some other way.

   Rationale:

    This makes the semantics of DEFCONSTANT consistent with constant
    declarations in other languages; thus this is a tried and proven
    approach and will reduce confusion for programmers moving from one
    language to another.  

   . . . 

After careful reconsideration of this proposal, this is *not* 
what Lucid does.  See especially the discussion further below
concerning the "second part".

First, let me say that I share your concern about the weird 
semantics of DEFCONSTANT in the existing proposal -- that it's 
decision to evaluate at compile time is based on "examination" 
of the form to be evaluated.  Long ago I expressed a desire for 
it to be a simpler decision making process.  Either let the 
default be implicitly eval-when(eval compile load) just like 
the "7 extremely randoms", or let it be like any other toplevel 
form.  To me, this really isn't such a big issue, because no
matter what the decision, there will be a significant number of
defconstant usages that need it the other way.  In the Lucid
system sources, there are scores, if not hundreds, of eval-whens
to alter the default evaluation timings for defconstants and
defmacros.

So in one sense, the default state -- to eval-at-compile or not
to eval-at-compile -- is an arbitray and voteable question.
Lucid does in fact treat both defconstant and defmacro just
like the "7 Randoms" -- those at top-level **without a user
supplied eval-when** are implicitly eval-when(eval compile load).
This kind of simplicity is one of the two things you are calling 
for, right?


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.  


If you are really serious about this counter proposal, then I'd
certainly like to see it broken up into two parts:

  (1) DEFCONSTANT is implicitly eval-when(eval compile load),
      just like a bunch of the other randoms

  (2) The load-time SETQ for a DEFCONSTANT is to the object
      obtained by the compile-time evaluation.  In effect,
      compiling a defconstant treats:
	(defconstant mumble (do-my-evaluation))
      as if it were:
        (defconstant mumble '#.(do-my-evaluation))

I suspect that this latter point is what you are stressing in
the Rationale part when you say:
    
    This makes the semantics of DEFCONSTANT consistent with constant
    declarations in other [conventional??] languages;  ...




-- JonL --