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 

"$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".


Reply via email to