Hi,
this is the way things used to be in Haskell 1.4 (if you are curious
take a look at page 21 of
http://haskell.org/definition/haskell-report-1.4.ps.gz). I am not
exactly sure why the change with the "fail" method happened but I
think it had something to do with concerns that depending on the
pattern your program might get a different constraint (e.g. Monad vs.
MonadPlus). To me this seems perfectly reasonable I don't know why
it was perceived as a problem.
-Iavor
PS: I believe at the time of Haskell 1.4 the MonadPlus class was split
into two parts MoandZero with just "zero" and a superclass that added
the "plus" method. The idea is the same though.
On Mon, Nov 28, 2011 at 3:43 PM, Evan Laforge
With a separate MonadFail class we have 4 options:
1) Simply translate to: "e >>= \p -> do{stmts}" instead. This means pattern match errors are always turned into errors.
2) Give all do-expressions a MonadFail constraint.
3) Only give do-expressions with pattern bindings a MonadFail constraint.
4) Only give do-expressions with pattern bindings with uncomplete patterns a MonadFail constraint.
I'm sure this has been brought up in the many 'fail' discussions that have occurred, but what about MonadPlus and substituting a refuted pattern match with mzero? The only time I've used refutable pattern matches is in a list or parser where something like "'a' <- Parse.char" is convenient. What about pattern matches desugaring as something like
tmp <- Parse.char case tmp of 'a' -> { ... rest of do block ... } _ -> mzero
Of course that just replaces MonadFail with MonadPlus and how to decide if the extra constraint is needed is still unsolved, but at least it's an already existing class.
I originally wanted to ask for uses of 'fail', because I haven't heard of any of those, but then I thought of how I use refutable pattern matches. And then that made me think the way fail takes a String is awkward and weird and none of my refutable matches make use of that fact. Then that made me think reusing MonadPlus's mzero seemed more appropriate.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries