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