defconstant

[nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet]

>From: Shasta!NGALL@G.BBN.COM
>Message-Id: <[G.BBN.COM]20-Jun-86 22:29:37.NGALL>
>
>File foo contains:
>
>(defconstant const ...)
>...
>
>File bar contains:
>
>(defun zap (x)
>  ... (reference const x) ...)
>
>Now suppose that I compile file bar in an environment in which I have
>already loaded foo.  Thus the compiler will recognize that the
>reference to const in zap is a reference of a constant.
>
>....
>
>But how about an implementation that does the following:  It
>substitutes a reference to a slot in the compiled function's "constant
>vector" (i.e., the piece of data where most implementations store
>constant values). BUT it does not init the slot at compile time (like
>most implementations), instead, it generates code that will init. the
>slot to the value that const has at load time!
>....
>
>What do you think?  By the way, thre does exist such an
>implementation: KCL.
>
>	-- Nick

Our implemenatation for constant references in compiled code is based on
the following statement of CLtL page 68.

	DEFCONSTANT name initial-value [doc]			[Macro]
	...

	DEFCONSTANT ... does assert that the value of the variable NAME is
	*fixed* and does license the compiler to build assumptions about the
	value into programs being compiled.

My interpretation is that the compiler can safely assume that variable NAME
will never be MAKUNBOUNDed.  With this interpretation, Nick's example above
is certainly an error.  As far as I know, this interpretation of mine does
not contradict any CLtL statements, as Scott said in his message:

>From: "Scott E. Fahlman" <Shasta!Fahlman@C.CS.CMU.EDU>
>Subject: defconstant
>In-Reply-To: Msg of 20 Jun 1986  22:29-EDT from NGALL at G.BBN.COM
>
>I agree with Nick's analysis.  A reference to a constant may be compiled
>as a variable reference or the value of the constant at compile time may
>be wired into the code, but if the latter is done, this should not
>depend on the constant having been initialized at load time.  I agree
>that the manual is too vague on this point, and should be clarified.

If my interpretation is not what CLtL intends, I am very glad to change
our implementation, whether or not the intension is stated explicitly in CLtL.
However, before doing the change, let me tell you some details about KCL.

>I suspect that KCL handles Defconstant this way in order to optimize the
>use of lists as constants, while still observing the requirement that
>all references to the constant must be EQL to one another, but this is a
>very tricky business and is probably not worth the trouble it takes to
>get it right.
>
>-- Scott

It IS worth the trouble!!  The KCL loader, when it loads a compiled code file,
stores the values of constants into fixed locations (NOT into a "constant
vector" as Nick guessed).  Each reference to a constant within a compiled code
directly refers to the fixed location.  This referencing operation IS faster
than retrieving the value from the symbol cell, which requires some kind of
indexing (hardware indexing, perhaps).  (The portable C code generated by
the KCL compiler looks as if it references constants by indexing, but this is
one of the well-known C fakes commonly used by C programmers.)

-- Taiichi