On Sun, Apr 25, 2010 at 4:05 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sun, Apr 25, 2010 at 9:49 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
Alessio Stalla alessiostalla@gmail.com writes:
On Sun, Apr 25, 2010 at 8:37 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi all,
On Sun, Apr 25, 2010 at 7:26 PM, Alan Ruttenberg alanruttenberg@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:
- 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 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?
I agree almost completely, but I'd like to add that:
- if EQL is modified, then EQUAL must be modified as well because
(eql x y) should always imply (equal x y)
EQUAL does not internally call EQL? If that's indeed not the case, perhaps it should be made so?
Maybe it does, I was reasoning in the abstract, I meant: let's ensure that EQUAL works consistently.
- if we have freedom to modify EQL and EQUAL, then I'd say that EQUAL
should call Object.equals(), but I know this is controversial
No that would be false reasoning IMHO. The only reason why it's acceptable to extend EQL that way is because the Notes section in EQL kind of implies (albeit does not spell it out explicitly) certain implementational freedom in the interplay of EQ and EQL.
I don't read more implementational freedom in EQL than in EQUAL.
I concur, though the kinds of freedoms are spelled out. Java .equals() doesn't seem to have the same constraint that lisp equals has - namely that the comparison is structural.
My read is that == on the java side is eql on the lisp side, that equals on the java side is it's own thing, and that we would be on the right side to define lisp equal and equalp on java objects such as arraylists in such a way that the comparison is elementwise as would be done on the lisp side.
-Alan
For EQL, the precise rules are:
"The value of eql is true of two objects, x and y, in the folowing (sic) cases:
- If x and y are eq.
- If x and y are both numbers of the same type and the same value.
- If they are both characters that represent the same character.
Otherwise the value of eql is false."
The notes then say a more general thing, that "eql tells whether two objects are conceptually the same, whereas eq tells whether two objects are implementationally identical".
For EQUAL, instead:
"Returns true if x and y are structurally similar (isomorphic) objects" describes it in general, as EQL is described in general in its notes.
Then the precise rules are set:
"Objects are treated as follows by equal. [...] Other (Structures, hash-tables, instances, ...)
Two other objects are equal only if they are eq."
So, both are presented with a description in natural language that seems to concede leeway for an extension, but are also described by a very strict set of rules. Whether those rules permit extensions or not depends on whether non-CL objects, like Java objects, are considered "objects" as defined by the CL standard or not. Imho, there are valid rational arguments for both interpretations, but the second one (Java objects are not Lisp objects) is the most practical in my opinion.
Alessio
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel