fail, MonadFail, or MonadPlus? (was Re: broken Monad Either instance?)
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.
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
On December 8, 2011 20:15:57 Iavor Diatchki wrote:
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.
That would seem like reasonable behavior to me as well. Cheers! -Tyson
On December 8, 2011 20:15:57 Iavor Diatchki wrote:
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.
I would think the only other option (presumably what we do now?) would be to define fail as error for monads where it doesn't make sense. This, however, strikes me as something not very much in the spirit of haskell as it seems to be pushing compile time issues to runtime. Cheers! -Tyson
participants (3)
-
Evan Laforge -
Iavor Diatchki -
Tyson Whitehead