In this code:
given False {
when True { say "True" }
when False { Say "False" }
default { say "Dairy" }
}
I don't think it's unreasonable to expect the output to be "False".
However, it actually outputs "True". Why? Well, because it's in the
spec that way. So... why is it in the spec that way?
I gave it some thought, and I can't imagine a reason that
smart-matching against True and False wouldn't be like smart-matching
against any other value type. That is, it should simply return $_ ===
True or $_ === False. Instead, a smart match always returns its right
hand side argument when that argument is Bool.
I'd suggest re-writing S03 like so:
$_ X Type of Match Implied Match if (given $_)
====== ===== ===================== ===================
...
Any Bool Test for boolean state ?$_ === ?X
and remove the first two lines (True and False which say we should parsewarn).
While I'm on the topic...
Why does "but" affect "===" on high level types which define a WHICH
method (for those unaware, === compares value types, but when you use
it for high level, user-defined types, it invokes .WHICH on its LHS
and RHS and compares the results recursively).
$ ./perl6 -e 'class R{ method WHICH() { 1 } } ; say R.new() === R.new()'
1
$ ./perl6 -e 'class R{ method WHICH() { 1 } } ; say R.new() ===
R.new() but False'
0
It doesn't seem to change the WHICH method:
$ ./perl6 -e 'class R{ method WHICH() { 1 } } ; say (R.new but False).WHICH'
1
So what *is* changing?
Oh and PPS: a kind of Rakudo bug:
$ ./perl6 -e 'class R{ method WHICH() { self } } ; say R.new() === R.new()'
Segmentation fault
Clearly this is infinitely recursive, but one imagines it would be
easy enough to put a maximum recursion depth on ===. I was about to
say that === should check to see if X.WHICH eqv X, but I think that
would slow things down too much. Setting a max recursion depth, on the
other hand would be simple and fast.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
