
I updated trac to reflect this discussion.
On October 25, 2018 1:45:40 PM UTC, Edward Kmett
While I’m weakly against the IsString version, I’m pretty strongly against both of these variants. They actively get in the way of a user who wants to treat the parameter uniformly.
-Edward
On Oct 25, 2018, at 8:06 AM, Daniel Bergey
wrote: I meant something like
foo :: MonadFail m => A -> m Foo
Sorry if my first version without input caused confusion.
On October 25, 2018 11:48:44 AM UTC, Daniel Bergey
wrote: When a library provides a funct foo :: MonadFail m => m Foo
I usually want to recover from failure while logging the failure message. I can do this with the IO instance, but then it's not obvius that all errors are getting caught. If I'm not in IO, and I want the error text, I think I'm out of luck.
Another option is to be agnostic about it with FlexibleInstances:
instance MonadFail (Either [Char]) where fail = Left
That'll work today, and leave the question of the ultimate constraint open. It's not Haskell 2010, but no one can take advantage of that fact.
I'm only raising that as an option; I don't really like it terribly much.
On Thu, Oct 25, 2018, 3:05 AM Edward Kmett
wrote: I'm also weakly inclined against it.
If we decided we really wanted something, then building a class
was
just for this purpose might work, sort of an updated version of
On October 25, 2018 7:21:51 AM UTC, David Feuer
wrote: that the old
'Error' class from transformers, but now limited to just the failure string so it has no extra baggage.
On the other hand, that then faces inertia problems all its own.
-Edward
On Wed, Oct 24, 2018 at 11:42 PM David Feuer
wrote: FWIW, I think I'm weakly opposed. Either is Haskell 98. MonadFail is solidly "standards-track" material, to the extent that designation is meaningful at the moment. IsString ... isn't. On Wed, Oct 24, 2018 at 10:44 PM Daniel Bergey
wrote: > > Is there still consensus in favor of adding this instance? > > instance IsString str => MonadFail (Either str) where > fail = Left . fromString > > In 2016 there was some discussion, and my reading is that there was consensus in favor at the time: > Trac: https://ghc.haskell.org/trac/ghc/ticket/12160 > libaries mailing list: https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
> > Does anyone know of a later decision not to add it, or was it simply no one's top priority? > > What is the next step to move this proposal forward? Is more discussion in order? Should I just submit a patch? > > Thanks, > bergey > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries