On Apr 25, 2010, at 5:51 AM, Alessio Stalla wrote:
On Sun, Apr 25, 2010 at 10:17 AM, Alan Ruttenberg alanruttenberg@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/c2f56ab69c93...
Thanks, I'll have a look later.
-Alan