Re: Smart match table
Luke Palmer
> 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
> 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
-------------- 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?
>
> 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.
>
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
> 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
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
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
> 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