Am Montag 05 Oktober 2009 16:22:15 schrieb Michael Mossey:
Eugene Kirpichov wrote:
[x,y,t,b,l,r] <- mapM (getStdRandom . randomR) [(-10,10), (-70,70), ...] return (BoxBounds ...)
Thanks.
I'm curious about the idea of "pattern matching in do-statements that can fail." This particular pattern cannot fail.
It can. It won't fail in this particular context, but it's a refutable pattern, that's what counts. Whether or not a pattern matching in a do-block can fail is intrinsic to the pattern.
I read that the "fail" function was introduced to Monad in order to handle pattern matches that fail, and that most members of haskell-cafe seem to think that was a mistake---that MonadZero should have been used instead. I.e., any do-block with a pattern that can fail should explicitly have a MonadZero class constraint.
This leads to my question about detecting pattern matches that could fail. We can easily prove the above pattern will never fail.
We can. And we could make the compiler able to prove it, too.
I'm wondering if the compiler infers this.
Not worth the hassle. One could make the compiler infer any finite number of special cases, but you can't have an algorithm that can for an arbitrary refutable pattern and an arbitrary monadic action (of appropriate type) decide whether the pattern match in pat <- act will always succeed.
And if a future version of Haskell dumps "fail" and used MonadZero to replace it, would that future Haskell compiler need to infer, in all cases, whether a pattern can fail? Is it simple enough to make that correct inference?
Using a refutable pattern would add the MonadZero constraint, while do-blocks with only irrefutable patterns can be had in any Monad. Whether a pattern is refutable or irrefutable is easy to decide (cf. http://haskell.org/onlinereport/exps.html#sect3.17).
Thanks, Mike