On Sun, Jan 28, 2001 at 02:43:44PM +0100, Raymond Wiker wrote:
> I've just spent a couple of hours getting CLX to build (and
> work :-) under SBCL again. The only things I had to change this time
> round were due to the change in behaviour of defconstant - I had to
> use sb-int:defconstant-eqx instead.
> Actually, I suspect that there is something wrong with the
> current behaviour of defconstant. Given a file containing only
> (defconstant *foo* :foo)
> If I compile this file, using (compile-file "test"), I can
> then evaluate *foo* to :foo. I.e, the defconstant from the compiled
> file modifies the running Lisp. This means that it is impossible to
> compile a file containing, say
> (defconstant *bar* '#(1 2 3))
> and subsequently loading this file.
> Is this the correct behaviour?
I think the biggest problem is that DEFCONSTANT is not a particularly
good name for the behavior specified by ANSI.
This is definitely conforming behavior. From the HyperSpec for
If a DEFCONSTANT form appears as a top level form, the compiler must
recognize that name names a constant variable. An implementation may
choose to evaluate the value-form at compile time, load time, or both.
Therefore, users must ensure that the initial-value can be evaluated
at compile time (regardless of whether or not references to NAME
appear in the file) and that it always evaluates to the same value.
The consequences are undefined if there are any bindings of the
variable named by name at the time DEFCONSTANT is executed or if the
value is not EQL to the value of INITIAL-VALUE.
So (DEFCONSTANT *BAR* #'(1 2 3)) is not conforming code, at least
not unless you make sure you never load it into the same image
which compiled it. If I understand correctly, the preferred
solution in most cases of non-EQL values, probably including this
one, is to use DEFVAR instead of DEFCONSTANT. (And thus it seems
to me that DEFCONSTANT is a rather non-mnemonic name. It certainly
seems to spawn controversy regularly on comp.lang.lisp.)
> While investigating this, I looked at the definition of
> sb-int:defconstant-eqx in src/code/primordial-extensions.lisp. It
> seems that there is a bug there; the main body of the macro evaluates
> expr twice (it should use expr-tmp in the defconstant form).
Yes, I think you're right. I'll make a note to myself to check in the
fix after my hacking on intersection types settles down. Maybe around
the same time I'll finally get around to trying the suggestion from
your 2000-12-01 mail, too:
I also suggested that "-Xlinker -export-dynamic"
might work under OpenBSD instead of simply
"-export-dynamic" - has anybody looked at this?
> CLX currently builds and works (for some of the demos, at
> least). It requires a working internet.lisp, which I've also worked
> on. This is possibly something that other SBCL users may have an
> interest in - should I put it on a web server somewhere?
> Alternatively, should it be put under SBCL's "contrib" directory?
That sounds useful to me. (Not useful to me personally, at least not
for a while, but useful on general principles.) Unless it's incredibly
huge, I'd be happy to use SBCL's SourceForge site to make it
available. How big is it? If it's small, it could be in contrib/.
Otherwise, I'd prefer to put it in the anonymous ftp area if you
consider it experimental, or if you prefer, and if you think you'll be
supporting it for a while, to make it into a separately released
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C