Re: Smart match table

7 views
Skip to first unread message

Luke Palmer

unread,
Feb 8, 2006, 6:54:39 PM2/8/06
to Robin Houston, perl6-l...@perl.org
On 2/7/06, Robin Houston <ro...@cpan.org> wrote:
> Any undef undefined match if !defined $a
> Any Regex pattern match match if $a =~ /$b/
> Code() Code() results are equal match if $a->() eq $b->()
> Any Code() simple closure truth match if $b->() (ignoring $a)
> Num numish[!] numeric equality match if $a == $b
> Any Str string equality match if $a eq $b
> Any Num numeric equality match if $a == $b
>
> which retains commutativity in all cases. Of course it's
> different in Perl 6, because the "dotted entries" like
> .[number] and .method need to behave non-commutatively.
> But is it really necessary for coderefs?

My interpretation (which may be totally off, as I don't have any
confirmation that anybody else is thinking the same way I am) is that
the synopsis is wrong, and commutivity of ~~ is a happy coincidence
wherever it exists. The way I've been thinking about ~~ is just as
the following object-oriented sugar:

role Pattern {
method match(Any $x) {...}
}
sub infix:<~~> (Any $x, Pattern $y) {
$y.match($x);
}

And then the interpretation of ~~ is determined by its right-hand side.

Luke

Damian Conway

unread,
Feb 8, 2006, 7:02:43 PM2/8/06
to perl6-l...@perl.org
Luke wrote:

> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.

Heavens, I hope not!

The whole point of ~~ is that it's dispatched multimorphically, *not*
polymorphically. So you get the most appropriate matching behaviour
for the *combination* of arguments.

And I've always imagined that it's commutative for the same reason ==
and eq are communative: because that's the only thing that makes
sense. When you're comparing two apples (or an apple and a
handgrenade), it shouldn't matter which of the two is in your left
hand, and which is in your right.

Damian

Mark A Biggar

unread,
Feb 8, 2006, 7:17:46 PM2/8/06
to Luke Palmer, Robin Houston, perl6-l...@perl.org

-------------- Original message ----------------------
From: Luke Palmer <lrpa...@gmail.com>
> On 2/7/06, Robin Houston <ro...@cpan.org> wrote:
> > Any undef undefined match if !defined $a
> > Any Regex pattern match match if $a =~ /$b/
> > Code() Code() results are equal match if $a->() eq $b->()
> > Any Code() simple closure truth match if $b->() (ignoring $a)
> > Num numish[!] numeric equality match if $a == $b
> > Any Str string equality match if $a eq $b
> > Any Num numeric equality match if $a == $b
> >
> > which retains commutativity in all cases. Of course it's
> > different in Perl 6, because the "dotted entries" like
> > .[number] and .method need to behave non-commutatively.
> > But is it really necessary for coderefs?
>
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists. The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
>
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
>
> And then the interpretation of ~~ is determined by its right-hand side.
>
> Luke

Also ermemebr that a very common user of ~~ is the implisit use in a when conditional inside a given block, which is an inheirently assymeterical (thus non-communitive) situation.


--
Mark Biggar
ma...@biggar.org
mark.a...@comcast.net
mbi...@paypal.com

Mike Guy

unread,
Feb 8, 2006, 1:32:12 PM2/8/06
to perl6-l...@perl.org
Robin Houston <ro...@cpan.org> wrote

> Any Code() simple closure truth match if $b->() (ignoring $a)

I obviously missed that when it went past on p5p. Surely that should
read

Any Code() predicate(value) match if $b->($a)

meaning that $a satisfies the predicate implemented by the code $b?

Ignoring $a seems a completely stupid thing to do.


Mike Guy

David Green

unread,
Feb 9, 2006, 7:23:35 PM2/9/06
to perl6-l...@perl.org

On 2/8/06, Mike Guy wrote:
>I obviously missed that when it went past on p5p. Surely that should read
> Any Code() predicate(value) match if $b->($a)
>meaning that $a satisfies the predicate implemented by the code $b?
>Ignoring $a seems a completely stupid thing to do.

Well, the ~~ table includes both:
Any Code<$> scalar sub truth match if $b($a)
Any Code<> simple closure truth match if $b() (ignoring $a)

so if the code takes a single argument, it will use $a; if it
doesn't, then, well, it won't.


-David "feeling singularly argumentative today" Green

Stuart Cook

unread,
Feb 9, 2006, 7:31:53 PM2/9/06
to perl6-l...@perl.org

IIRC, that rule exists so you can create when-clauses that don't
involve the current topic, without having to explicitly throw it away.
This is useful when using given/when to replace a sequence of elsifs,
when not all of them use $_.

The problem, as I see it, is that you can't really have all three of
the following:
1) Sensible (symmetric, non-ignoring) behaviour of `~~`
2) Simple correspondence between `when` and `~~`
3) Sensible (dwimmy) behaviour of `when`

Currently, it's (1) that's been lost. Now, personally I wouldn't mind
exchanging it for (2), but there certainly are valid reasons for
wanting to keep (2).


Stuart

Stuart Cook

unread,
Feb 9, 2006, 7:37:23 PM2/9/06
to perl6-l...@perl.org
On 10/02/06, Stuart Cook <sco...@gmail.com> wrote:
> IIRC, that rule exists so you can create when-clauses that don't
> involve the current topic, without having to explicitly throw it away.
> This is useful when using given/when to replace a sequence of elsifs,
> when not all of them use $_.

(In light of David's response, it seems what I wrote is not 100%
correct, so please ignore.)


Stuart

Reply all
Reply to author
Forward
0 new messages