[cdr-discuss] AEQUALIS and COMPARE
Good morning. here is a proposal to introduce generic equality and comparisons in CL. The proposal is minimal and it is in the spirit of Java and C# equality facilities. The names are not fixed in stone. Please let's discuss it in this spirit. I am well aware of KMP's considerations on the subject and of other issues as well. -- Marco Antoniotti
Hi, Just a few quick comments: - The name AEQUALIS seems very weird to me. ;) - The idea that COMPARE returns symbols also seems weird to me. Wouldn't it be better to return numbers (-1, 0, +1 or NIL)? Can't immediately tell why, though. - Shouldn't there also be a hash-code generic function that can be specialized alongside AEQUALIS? This also exists in Java and C#, and could make this immediately more useful (and would be much harder to add later as an afterthought). Many CL implementation add an :sxhash option to make-hash-table, where such a hash-code function could be used. Best, Pascal On 15 Feb 2011, at 08:04, Marco Antoniotti wrote:
Good morning.
here is a proposal to introduce generic equality and comparisons in CL. The proposal is minimal and it is in the spirit of Java and C# equality facilities. The names are not fixed in stone.
Please let's discuss it in this spirit. I am well aware of KMP's considerations on the subject and of other issues as well.
<cleqcmp.pdf> <cleqcmp.html>
-- Marco Antoniotti
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium
- The idea that COMPARE returns symbols also seems weird to me. Wouldn't it be better to return numbers (-1, 0, +1 or NIL)? Can't immediately tell why, though.
you need to return well-known identities that communicate the result. -1,0,+1 are the easy way for well-known identities in C. in CL, symbols provide a much nicer framework to deal with well-known identities IMO.
- Shouldn't there also be a hash-code generic function that can be specialized alongside AEQUALIS? This also exists in Java and C#, and could make this immediately more useful (and would be much harder to add later as an afterthought). Many CL implementation add an :sxhash option to make-hash-table, where such a hash-code function could be used.
a big +1 for the above. -- attila Notice your eroding (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
On Feb 15, 2011, at 14:36 , Attila Lendvai wrote:
- The idea that COMPARE returns symbols also seems weird to me. Wouldn't it be better to return numbers (-1, 0, +1 or NIL)? Can't immediately tell why, though.
you need to return well-known identities that communicate the result. -1,0,+1 are the easy way for well-known identities in C. in CL, symbols provide a much nicer framework to deal with well-known identities IMO.
That was the thinking.
- Shouldn't there also be a hash-code generic function that can be specialized alongside AEQUALIS? This also exists in Java and C#, and could make this immediately more useful (and would be much harder to add later as an afterthought). Many CL implementation add an :sxhash option to make-hash-table, where such a hash-code function could be used.
a big +1 for the above.
You should but: As in Java (and FWIU in C#) there are no "easy" ways (for an appropriate definition of "easy") to enforce the protocol. What would be the default? Something like (defmethod hash-code ((x t)) (sxhash x)) If you think so, I can add it to the doc. Always with the caveat that there is no way to enforce the relationship between equality and hashing. Marco PS. Yeah. AEQUALIS is very Latin :) Any synonym? I will just vote against EGAL, which I really don't like :)
-- attila
Notice your eroding (digital) freedom, and do something about it!
PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
-- Marco Antoniotti
On 15 Feb 2011, at 15:21, Marco Antoniotti wrote:
On Feb 15, 2011, at 14:36 , Attila Lendvai wrote:
- The idea that COMPARE returns symbols also seems weird to me. Wouldn't it be better to return numbers (-1, 0, +1 or NIL)? Can't immediately tell why, though.
you need to return well-known identities that communicate the result. -1,0,+1 are the easy way for well-known identities in C. in CL, symbols provide a much nicer framework to deal with well-known identities IMO.
That was the thinking.
OK.
- Shouldn't there also be a hash-code generic function that can be specialized alongside AEQUALIS? This also exists in Java and C#, and could make this immediately more useful (and would be much harder to add later as an afterthought). Many CL implementation add an :sxhash option to make-hash-table, where such a hash-code function could be used.
a big +1 for the above.
You should but:
As in Java (and FWIU in C#) there are no "easy" ways (for an appropriate definition of "easy") to enforce the protocol. What would be the default? Something like
(defmethod hash-code ((x t)) (sxhash x))
If you think so, I can add it to the doc. Always with the caveat that there is no way to enforce the relationship between equality and hashing.
Yes, that's an important remark. I nevertheless think it's important, because then people have at least a place to hang their hat on. The default implementation for hash-code looks good to me.
Marco
PS. Yeah. AEQUALIS is very Latin :) Any synonym? I will just vote against EGAL, which I really don't like :)
The good names are all taken, and I'm against adding a "?" to names in Common Lisp. ;) What about "EQUIVALENT" or "EQUIV", or "EQUIVP"? Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium
On Feb 15, 2011, at 15:57 , Nikodemus Siivola wrote:
On 15 February 2011 16:37, Pascal Costanza <pc@p-cos.net> wrote:
What about "EQUIVALENT" or "EQUIV", or "EQUIVP"?
Or "EQUALS" ?
Well, that looks ok, but it sort of implies a subject-verb-complement relation. I would go for EQUIV or even == (two equal signs). Cheers -- Marco Antoniotti
Marco Antoniotti wrote:
On Feb 15, 2011, at 15:57 , Nikodemus Siivola wrote:
On 15 February 2011 16:37, Pascal Costanza <pc@p-cos.net> wrote:
What about "EQUIVALENT" or "EQUIV", or "EQUIVP"?
Or "EQUALS" ?
Well, that looks ok, but it sort of implies a subject-verb-complement relation.
I would go for EQUIV or even == (two equal signs).
EQUALS gets +1 from me. Personally I don't think it implies a subject-verb structure any more than existing binary predicates like EQUAL. It also shows nicely where the concept is coming from. Leslie
On 15 Feb 2011, at 16:49, Leslie P. Polzer wrote:
Marco Antoniotti wrote:
On Feb 15, 2011, at 15:57 , Nikodemus Siivola wrote:
On 15 February 2011 16:37, Pascal Costanza <pc@p-cos.net> wrote:
What about "EQUIVALENT" or "EQUIV", or "EQUIVP"?
Or "EQUALS" ?
Well, that looks ok, but it sort of implies a subject-verb-complement relation.
I would go for EQUIV or even == (two equal signs).
EQUALS gets +1 from me.
I don't think EQUALS is ideal, because it may be easily confused with EQUAL or EQUALP when skimming through source code. (I recall having that problem with EQUAL and EQUALP in the past.) I don't think that's a critical objection, but I wanted to mention this nevertheless. As an additional thought: It may be a good idea to impose a restriction on the generic functions similar to bullet 19 in http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm - this would allow CL vendors to recognize uses of the functions on predefined types and optimize them without regard for potential user-defined methods, and it would make interaction of independently developed libraries safer. (For the latter to be really safe, the wording should say something like that at least one of the required parameters in a method definition should be specialized to one of your "own" classes. Not sure if this could be worded in a watertight way...) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium
What about "EQUIVALENT" or "EQUIV", or "EQUIVP"?
Or "EQUALS" ?
+1 from me, too. (although i'll probably deal with the conflict using package hackery)
SAMEP
-1 (to me the word "same" suggests identity) -- attila Notice your eroding (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB
On 15 Feb 2011, at 14:36, Attila Lendvai wrote:
- The idea that COMPARE returns symbols also seems weird to me. Wouldn't it be better to return numbers (-1, 0, +1 or NIL)? Can't immediately tell why, though.
you need to return well-known identities that communicate the result. -1,0,+1 are the easy way for well-known identities in C. in CL, symbols provide a much nicer framework to deal with well-known identities IMO.
I guess my main reason for suggesting fixnums as return values here is that they are easier to use for table lookups. Not sure if that's very relevant, though... (svref some-table (1+ (compare this that))) Pascal -- Pascal Costanza, mailto:pc@p-cos.net, http://p-cos.net Vrije Universiteit Brussel Software Languages Lab Pleinlaan 2, B-1050 Brussel, Belgium
AEQUALIS a b &optional recursive-p &rest keys &key &allow-other-keys → result Note: Maybe it would make sense to supply a \:key parameter (defaulting to identity) as well. ...
COMPARE a b &optional recursive-p &rest keys &key &allow-other-keys → result
What is the rationale for making recursive-p an optional argument instead of a keyword argument? It generates style warnings and makes it clumsy to delegate to aequalis/compare in other functions. Matt
On Feb 25, 2011, at 19:58 , Matthew Swank wrote:
AEQUALIS a b &optional recursive-p &rest keys &key &allow-other-keys → result Note: Maybe it would make sense to supply a \:key parameter (defaulting to identity) as well. ...
COMPARE a b &optional recursive-p &rest keys &key &allow-other-keys → result
What is the rationale for making recursive-p an optional argument instead of a keyword argument? It generates style warnings and makes it clumsy to delegate to aequalis/compare in other functions.
Aesthetics? It is nicer to write (equals #((foo)) #((bar)) t) than (equals #((foo)) #((bar)) :recursive-p t) What style warnings are generated and by which implementation? I don't get any. Cheers Marco
Matt
_______________________________________________ cdr-discuss mailing list cdr-discuss@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cdr-discuss
-- Marco Antoniotti
Marco Antoniotti <marcoxa@cs.nyu.edu> writes:
On Feb 25, 2011, at 19:58 , Matthew Swank wrote:
What is the rationale for making recursive-p an optional argument instead of a keyword argument? It generates style warnings and makes it clumsy to delegate to aequalis/compare in other functions.
Aesthetics? It is nicer to write
(equals #((foo)) #((bar)) t)
than
(equals #((foo)) #((bar)) :recursive-p t)
What style warnings are generated and by which implementation? I don't get any.
Mixing &optional and &key arguments in a lambda list is an excellent way to cause confusion down the line; is it nicer to write (equals #S(foo :a 1) #S(foo :a 2) :mykey t) or (equals #S(foo :a 1) #S(foo :a 2) nil :mykey t) ? SBCL generates style warnings if you mix &optional and &key in a lambda list, mostly to warn people with dubious aesthetics that it's a fairly bad idea. (See also the FAQ about READ-FROM-STRING). Best, Christophe
Fair enough. I don't have a problem making recursive-p a key. I'll set up another vote. Cheers Marco On Feb 26, 2011, at 09:53 , Christophe Rhodes wrote:
Marco Antoniotti <marcoxa@cs.nyu.edu> writes:
On Feb 25, 2011, at 19:58 , Matthew Swank wrote:
What is the rationale for making recursive-p an optional argument instead of a keyword argument? It generates style warnings and makes it clumsy to delegate to aequalis/compare in other functions.
Aesthetics? It is nicer to write
(equals #((foo)) #((bar)) t)
than
(equals #((foo)) #((bar)) :recursive-p t)
What style warnings are generated and by which implementation? I don't get any.
Mixing &optional and &key arguments in a lambda list is an excellent way to cause confusion down the line; is it nicer to write
(equals #S(foo :a 1) #S(foo :a 2) :mykey t)
or
(equals #S(foo :a 1) #S(foo :a 2) nil :mykey t)
? SBCL generates style warnings if you mix &optional and &key in a lambda list, mostly to warn people with dubious aesthetics that it's a fairly bad idea. (See also the FAQ about READ-FROM-STRING).
Best,
Christophe
-- Marco Antoniotti
participants (8)
-
Attila Lendvai -
Christophe Rhodes -
Gary King -
Leslie P. Polzer -
Marco Antoniotti -
Matthew Swank -
Nikodemus Siivola -
Pascal Costanza