Re: [Sbcl-devel] Re: similarity in SBCL (was Re: Putting CLX under CLOCC?)

[Martin A. <ma...@at...>]

Peter Van Eynde wrote:
> 
> On Fri, Feb 02, 2001 at 07:01:21PM -0600, William Harold Newman wrote:
> > It looks as though Bruno is right: I screwed up by changing the
> 
> I'm not so certain, as the defconstant documentation says:
> 
>    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.
> 
> And with 'same value' I think they mean 'EQL'.
There were some threads on comp.lang.lisp in 1999 about "defconstant"
and its
intended behavior by ANSI. And the overall consensus seems to support
the "similar
is EQL" view. So, SBCL may be doing the right thing after all ...

Quoting from the news ...

<QUOTE>
From: Kent M Pitman <pi...@wo...>
Subject: Re: what is DEFCONSTANT (Ex: Re: `fast' global variables #)
Date: 24 Mar 1999 00:00:00 GMT
Sender: pi...@wo... (Kent M Pitman)

Newsgroups: comp.lang.lisp

mi...@mi... (Mike McDonald) writes:

> But I'll concede that the spec is confused and inconsistant enough that just
> about any interpretation is possible, rendering DEFCONSTANT pretty close to
> useless.

This is one of the few "obviously wrong" statements in this whole
discussion.
All it means is that a certain set of possible uses of DEFCONSTANT is
ruled
out.  It doesn't mean that DEFCONSTANT is useless.  There is a set of 
well-understood uses that are not problematic.

More clarification would broaden its scope of usefulness.  The present
situation plainly calls for more "defensive programming style" than
one might wish for.

> Its spec requires some CLOS instances to be the value of a constant variable,
> typically to be used in generic functions using the eql specifier.  But since
> EQL doesn't work on "similar", I don't know what to do about them. How does
> one test for similarity?

Conceptually, similar exists to implement EQL across address spaces.
You cannot test for it because it is "defined".

How can two packages in two different lisp images be EQL?  They aren't
pointer-equivalent.  But they can be similar because the definition of
similarity is not pointer-based.

Although not defined this way, I think of EQL and "similar" as
denoting the same concept but simply implemented differently.  I
consider anyone writing a make-load-form that does not yield an EQL
object when the form is loaded into the originating environment as
having made an error (perhaps except where the semantics of the object
is such that it can be proven it will never have EQL called on it--small
amount of wiggle room there).
</QUOTE>

AND

<QUOTE>
From: Jeff Dalton <je...@to...>
Subject: Re: Should compilers be allowed to save space by "aliasing?"
Date: 21 Dec 1999 00:00:00 GMT

Newsgroups: comp.lang.lisp

"Martin Simmons" <ma...@ha...> writes:

> Jeff Dalton <je...@to...> wrote in article
> <x2z...@to...>...
> 
> > I have another question about defconstant, though.  If a defconstant
> > is evaluated more than once, the results have to be EQL; and an
> > implementation is allowed to eval the form at both compile and
> > load time.  Doesn't that make it rather difficult to use defconstant
> > for any case where the value is a different (not EQL) object each
> > time?
> 
> I think this is an environments issue. If you have a compiler which uses a
> separate compilation environment, then the compile and load time values
> won't interfere.  OTOH, if your compiler uses the global environment at
> compile time, then "the consequences are undefined" but of course any given
> compiler can define the consequences to do something sensible.

[...]
</QUOTE>


Cheers,

Martin

-- 
Martin Atzmueller <ma...@at...>