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