[Haskell-cafe] better way to do this?

[Daniel Fischer]

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