[armedbear-devel] eql for java objects

[Alan Ruttenberg]

On Apr 25, 2010, at 5:51 AM, Alessio Stalla wrote:

> On Sun, Apr 25, 2010 at 10:17 AM, Alan Ruttenberg
> <alanruttenberg at gmail.com> wrote:
>> (eql (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle")
>> (jfield-raw "org.armedbear.lisp.Stream" "platformEolStyle"))
>> ->
>> NIL
>> I think it should be eql, probably eq.
>> I know they are equal.
>> 
>> The documentation for eq says:
>> Returns true if its arguments are the same, identical object;
>> otherwise, returns false.
>> 
>> They are and they are not. That they are not is only a quirk of the
>> implementation.
> 
> Well, eq is supposed to work following "quirks of the implementation",
> for example, eql fixnums are not required to be eq and indeed they are
> not on abcl due to boxing.

By my understanding this was a known quirk, and so give insight into why eql was created. BTW, to be clear, "quirk" was a friendly, not a fighting work :)

> So two boxed java objects are not eq.

Willing to accept that, as long as they are eql. After all, they are the "same, identical object" in the java sense, and we are trying to integrate with java.

>> eql adds equality for characters and numbers
> 
> right, and equal should provide equality for compound objects,
> descending their structure. But the standard explicitly says that
> equal behaves like eq for all objects excepts for those types
> mentioned in the definition of equal.

I'm not interested in equal, really, just noted that as in reading the code I see that JavaObject.equal() is defined. My sense is that this is misplaced and that JavaObject.eql() should be instead defined, to be true when two things are the "same, identical object" on the java side.

I think this because eql isolates us from implementation details which numbers are boxed and which not, and because it certainly could be the case that in a future abcl java objects are not boxed, and so eql would isolate us from this choice as well.

> I encountered this problem too
> in the past and I tried to understand it better by carefully reading
> the Hyperspec and by asking people on comp.lang.lisp about it. It
> seems that there's not a uniform opinion in the Lisp community: some
> say that the standard prohibits implementations from giving EQUAL a
> new meaning for "non-CL" objects. Others say that implementation can
> and sometimes should change CL functions giving them new meanings for
> implementation-specific objects. Others still say that implementations
> can extend EQUAL, but should not do it to avoid surprising the users.
> I personally think that position #2 is the most sensible in this case,
> but it's hard to get it right, because some people think #2 and #3
> break CL conformance.

Again, equal is not my concern. It's eql.

> If you're interested, the discussion on c.l.l. is here:
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/c2f56ab69c936f67

Thanks, I'll have a look later.

-Alan