Re: Smart match table
Robin Houston [EMAIL PROTECTED] 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
Re: Smart match table
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 Codesimple 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
Re: Smart match table
On 09/02/06, Mike Guy [EMAIL PROTECTED] wrote: Robin Houston [EMAIL PROTECTED] 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. 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
Re: Smart match table
On 10/02/06, Stuart Cook [EMAIL PROTECTED] 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
Re: Smart match table
On 2/7/06, Robin Houston [EMAIL PROTECTED] wrote:
Any undef undefinedmatch if !defined $a
Any Regex pattern matchmatch if $a =~ /$b/
Code() Code()results are equalmatch 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
Re: Smart match table
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
Smart match table
The table of smart matches in S4 has this: ... Any Str string equality match if $_ eq $x ... Any Rule pattern matchmatch if $_ ~~ /$x/ ... By my (and Damian's) interpretation of the table, this means that string ~~ /rule/ would be interpreted as testing the *string equality* of its operands, rather than doing a pattern match. Clearly this is not the intention. Am I misreading the table, or is there a mistake? If the latter, what is the correct precedence order of the table entries? The other thing that seems odd to me is that $foo ~~ $bar where $foo and $bar are both references to Code, is defined to be equal to (the truth value of) $bar(). This seems an unnecessary violation of commutativity. For Perl 5, I changed the relevant part of the table to read Any undef undefinedmatch if !defined $a Any Regex pattern matchmatch if $a =~ /$b/ Code() Code()results are equalmatch 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? Is my implementation sufficiently in the spirit of the Perl 6 design? Thanks for your thoughts. Robin
