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. 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/c2f56ab69c93...
Bye, Alessio