On 2010-07-31, at 11:38 am, Brandon S Allbery KF8NH wrote: > Thank you; *that* is the real point I was trying to make. That, and that > special-casing one particular type is *not* actually helpful; it means I must > remember a special case, when one of the goals of Perl 6 was supposedly to > eliminate all the special cases in Perl 5, "helpful" or no.
I don't know if it was supposed to eliminate *all* special cases, but I'm happy that it eliminates lots of them. I think some exceptions can be justified if it's a way humans naturally think (though it may be "exceptional" to a machine), or if there is some construct that isn't useful at all (if it has no legitimate use, why not use that syntax to mean something else? — but in that case, the trade-off is remembering an exception [of something you'd never want to do anyway] versus remembering extra syntax to do the other thing). I'm even prepared to accept exceptions for something that isn't meaningless. (My no-exception rule has exceptions!) "0 but true" in P5 is a good example. The exception is that it suppresses a warning, and that warning isn't totally useless; there *could* be a situation where you accidentally get that exact string when you wanted a pure number, but it's unlikely *and* the warning doesn't actually do anything — the code works the same way with or without the warning. "$foo ~~ True" is different. It may be less useful than the exception in that it's less frequent; but it still has a legitimate (non-exceptional) meaning. A bear of little memory like me will see "when timeout()" but instead of internalising "P6 handles when $bool differently from when $anything-else", I will take away "Perl DWIM". And then I'll expect it to DWIM in "$true-false-queston ~~ $bool-answer". -David
