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
- 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.
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
On 15 February 2011 16:37, Pascal Costanza pc@p-cos.net wrote:
What about "EQUIVALENT" or "EQUIV", or "EQUIVP"?
Or "EQUALS" ?
Cheers,
-- Nikodemus
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
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)
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
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
-
Attila Lendvai -
Christophe Rhodes -
Gary King -
Leslie P. Polzer -
Marco Antoniotti -
Matthew Swank -
Nikodemus Siivola -
Pascal Costanza