[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: defconstant
Date: Tue, 24 Jun 86 13:07:15+0900
From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet
To: nttlab!Shasta!common-lisp@su-ai.arpa
Subject: defconstant
Message-ID: <8606240407.AA00961@kurims.kurims.kyoto-u.junet>
...
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:
I have been thinking about this issue for a while, and I now agree
with Taiichi: MAKUNBOUND is a form of assignment (it is even in the
assignment section of CLtL!); therefore my example violated the
assertion made by defconstant, since the value of the constant had no
value (i.e., a different value) at load time. What bothered me (and
still does) is that the "test" for violation occured at load time,
which I had never seen before nor expected. But I should not have let
my expectations color my interpretation of CLtL.
I even think that your implementation is "safer",
in that programmers are prevented from loading their files in a
different order than they compiled them.
Your handling of defconstant is simple and elegant, keep it in. But
be prepared for a few complaints since no (?) other implementation has
adopted your implementation technique.
-- Nick
- References:
- defconstant
- From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet