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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
