[armedbear-devel] eql for java objects

Tobias C. Rittweiler tcr at freebits.de
Sun Apr 25 19:56:03 UTC 2010

Erik Huelsmann <ehuels at gmail.com> writes:

> Hi all,
> On Sun, Apr 25, 2010 at 7:26 PM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> On Apr 25, 2010, at 6:55 AM, Tobias C. Rittweiler wrote:
>>> I think that's past Alan's point which, from my understanding, is simply
>>> "Java enums should be comparable by EQL." Makes perfect sense as EQL is
>>> for object identity.
>> Yes, and Java "objects" too.
> I've read this thread, the thread on c.l.l regarding EQUAL and the
> definitions of EQ and EQL. The following is my interpretation of it
> all:
> 1. Our Java side JavaObject class is merely a box for a Java instance
> value (a pointer to a Java object, if you will)
> 2. The definitions of EQ and EQL talk about Objects, but I interpret
> them to refer to the first meaning in [1], not to instances of lisp
> classes
> 3. Our JavaObjects have not been defined in the (Common) Lisp spec;
> they don't adhere to the object-instantiation protocol nor are they
> any of any one of the predefined built-in classes and therefore can't
> be taken to be "Lisp Objects" in that sense of the word

These JavaObjects are not a subtype of T?

> 4. From point (1) and the definitions of EQ and EQL, I concur with
> Alan that "raison d'etre" of EQL should equally apply to JavaObjects
> 5. From ponits (2) and (3) and the discussion on #lisp and c.l.l, I
> conclude that we're basically free to extend the meaning of EQL here:
> the JavaObject values were not in the spec to begin with: they're not
> Lisp class instances, they're not symbols, numbers nor characters
> The only objection there is from both #lisp and c.l.l is that EQ, EQL
> and EQUAL shouldn't start to behave unpredictably regarding defined
> behaviour. For all the spec cares, we would have generated an error
> when EQ-comparing 2 java objects...
> Agreed?

As also written in the reply to Alessio, I'd argue from the point that
the Notes section for EQL pretty much implies implementational freedom
regarding the behaviour of EQ and EQL.

ABCL extends that notion by adding these Java instance pointers to the
mix of numbers and characters.


More information about the armedbear-devel mailing list