On 1/16/07, Dave Whipp <[EMAIL PROTECTED]> wrote:
Synopsys 13 mentions an "is commutative" trait in its discussion of operator overloading syntax:> Binary operators may be declared as commutative: > > multi sub infix:<+> (Us $us, Them $them) is commutative { > myadd($us,$them) } A few questions: Is this restricted to only binary operators, or can I tag any function/method with the trait. The semantics would be that the current seq of ordered args to the function would be treated as a true (unordered) set for purposes of matching
Seems reasonable. My generality alarm goes off when I realize that you can't specify commutivity for two of the three args, but that's fine because it's definitely a cpanable feture.
Does the fact that a match was obtained by reordering the arguments affect the distance metric of MMD?
Well, aside from the fact that there's no "metric" per se, I'd say no. That is, I think saying: multi foo (Bar, Baz) is commutative Should be equivalent to defining: multi foo (Bar, Baz) multi foo (Baz, Bar) And if Bar does Baz then also: multi foo (Bar, Bar) And vice versa (this variant is to remove ambiguity by picking one of those methods, presumably the original (Bar, Baz) variant).
Will the use of this trait catch errors such as the statement "class quaternion does Num" that came up a few days ago on this list (multiplication of quaternions isn't commutative; but of Nums is).
Not unless you have explicitly stated somewhere, somehow, that quaternion multiplication is definitely not commutative. Roles often have laws that go with them, and Perl cannot use those laws to prove that you follow them. Instead, the laws should be encoded in a QuickCheckesque test suite. So in some way, it will catch those errors, but not at compile time: at test time.
Does the trait only apply within one region of the arglist, or can I create a 1-arg method that is commutative between the "self" arg and its data arg? (I assume not -- I can't quite work out what that would mean)
That's CPAN's job, I think. Luke
