Is DEFCONSTANT broken?

Consider the following code:

(eval-when (:load-toplevel :compile-toplevel :execute)

(defconstant foo ...)

(defun foo () foo)

)

Are there any circumstances under which, in an ANSI-compliant
implementation of CL, (equal foo (foo)) can return NIL?

It turns out that there are. I'll describe what those circumstances are
in a moment (makes a good exercise to figure it out on your own). The
question I want to raise is, given that this is the case, is this aspect
of DEFCONSTANT's behavior so at odds with intuition that it can be
considered broken? And if so, what, if anything, should be done about
it?

The circumstnaces under which (equal foo (foo)) can return NIL are the
following:

1. FOO is initialized by a non-idempotent initialization function like
GENSYM or GET-INTERNAL-REAL-TIME.

2. The code is compiled into a fasl file.

The reason this can lead to (equal foo (foo)) being NIL is that the spec
says:

"An implementation may choose to evaluate the value-form at compile
time, load time, OR BOTH." [Emphasis added.]

There is at least one popular implementation of CL (Clozure) that
actually takes advantage of this latitude and manifests the behavior I
describe. SBCL and CLisp apparently don't take advantage of it; they
both return T to (equal foo (foo)). I don't have a copy of Allegro or
Lispworks.

The "problem" (I put it in scare quotes because I consider it a problem
but reasonable people could disagree -- opening that discussion is the
point of posting this) is that "constant" can mean two different things:

1. A value that the user is not allowed to change.

2. A value that the compiler can assume (but is not obligated to
assume) won't change, but which might nonetheless actually change.

The ANSI spec implicitly uses definition 2. IMHO there is more utility
in definition 1.

Discuss.

rg
.

Quantcast