Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The S13 "is commutative" trait

1 view
Skip to first unread message

Dave Whipp

unread,
Jan 16, 2007, 2:19:45 PM1/16/07
to perl6-l...@perl.org
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)

Luke Palmer

unread,
Jan 16, 2007, 3:40:19 PM1/16/07
to Dave Whipp, perl6-l...@perl.org
On 1/16/07, Dave Whipp <da...@whipp.name> 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

Jonathan Lang

unread,
Jan 16, 2007, 4:41:30 PM1/16/07
to Luke Palmer, Dave Whipp, perl6-l...@perl.org
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

Larry Wall

unread,
Jan 17, 2007, 1:23:05 PM1/17/07
to perl6-l...@perl.org

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

0 new messages