[Haskell-cafe] IO (Either a Error) question

[wren ng thornton]

Brandon S. Allbery KF8NH wrote:
> It's not a call, it's a definition as shown above.  The simpler 
> translation is:
> 
>  > x <- y
> 
> becomes
> 
>  > y >>= \x ->
> 
> (note incomplete expression; the next line must complete it) and the 
> refutable pattern match takes place in the lambda binding.  But because 
> of the whole "fail" thing, instead of letting pattern match failure be 
> caught by the lambda binding it gets handled specially beforehand, which 
> is especially silly when in most cases fail is defined to do the same 
> thing as the lambda binding would.
> 
> I'm suggesting (as is David, I think) that a saner definition would let 
> the lambda binding randle refutable patterns, and for something like 
> Maybe (>>=) can decide how to deal with it in the usual way.  Otherwise 
> you're either using a default fail that duplicates the lambda binding, 
> or if you want custom handling (as with Maybe and Either that propagate 
> Nothing/Left _ respectively) you end up reimplementing part of (>>=) as 
> fail, which is just dumb.

+1.

I've never understood what exactly the goal of 'fail'-able patterns was. 
It's a *solution* to the problem of pattern matching, but what is the 
*goal* of allowing pattern matching in the first place? What semantics 
is the solution trying to capture?

The vast majority of code I've written or seen uses plain variables as 
the binding pattern, in which case the definition of (>>=) should handle 
issues like this. And in the cases where we want more than just a plain 
variable, we usually want to handle the "exceptional" branch on a 
case-by-case basis, so the pattern gets boiled out of the <- syntax anyways.

The only examples I can think of where we'd want 'fail'-able patterns 
are entirely pedagogical (and are insignificantly altered by not using 
'fail'-able patterns). I can't think of any real code where it would 
actually help with clarity.

-- 
Live well,
~wren