Re: The S13 is commutative trait
On Tue, Jan 16, 2007 at 01:41:30PM -0800, Jonathan Lang wrote: : Luke Palmer wrote: : Seems reasonable. My generality alarm goes off when I realize that : you can't specify commutativity for two of the three args, but that's : fine because it's definitely a cpanable feature. : : IIRC, it's possible to embed one signature within another one; if the : embedded signature has two parameters and is commutative while the : embedding signature is not commutative and has a third arg, wouldn't : that produce commutativity for two out of the three, as long as : they're adjacent? : : 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. : : IMHO, is commutative should only apply to positional args: named : args have this behavior automatically, and trying to include the : invocant would tend to interfere with the self-contained nature of : classes and roles - that is, it would allow role A to define a method : for role B. I've decided is commutative must die of ill-definedness. See instead the recent S13 change to support multiple signatures on a single body. This approach seems to be both more general and better defined. I like that, up to a point... Larry
The S13 is commutative trait
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
Does the fact that a match was obtained by reordering the arguments
affect the distance metric of MMD?
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).
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)
Re: The S13 is commutative trait
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
Re: The S13 is commutative trait
Luke Palmer wrote: Seems reasonable. My generality alarm goes off when I realize that you can't specify commutativity for two of the three args, but that's fine because it's definitely a cpanable feature. IIRC, it's possible to embed one signature within another one; if the embedded signature has two parameters and is commutative while the embedding signature is not commutative and has a third arg, wouldn't that produce commutativity for two out of the three, as long as they're adjacent? 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. IMHO, is commutative should only apply to positional args: named args have this behavior automatically, and trying to include the invocant would tend to interfere with the self-contained nature of classes and roles - that is, it would allow role A to define a method for role B. -- Jonathan Dataweaver Lang
