[armedbear-devel] eql for java objects

[Alessio Stalla]

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. So two boxed java objects are not eq.

> 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 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.

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

Bye,
Alessio