MonadFail instance for Either

Daniel Bergey bergey at teallabs.org
Thu Oct 25 18:04:54 UTC 2018


I updated trac to reflect this discussion.

On October 25, 2018 1:45:40 PM UTC, Edward Kmett <ekmett at gmail.com> wrote:
>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 <bergey at teallabs.org>
>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
><bergey at alum.mit.edu> 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.
>>> 
>>> On October 25, 2018 7:21:51 AM UTC, David Feuer
><david.feuer at gmail.com>
>>> wrote:
>>>> 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 <ekmett at gmail.com>
>wrote:
>>>>> 
>>>>> I'm also weakly inclined against it.
>>>>> 
>>>>> If we decided we really wanted something, then building a class
>that
>>>> was
>>>>> just for this purpose might work, sort of an updated version of
>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
><david.feuer at gmail.com>
>>>>> 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
>>> <bergey at alum.mit.edu>
>>>>>> 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 at haskell.org
>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>> _______________________________________________
>>>>>> Libraries mailing list
>>>>>> Libraries at haskell.org
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>> 
>>>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181025/9c98ab88/attachment.html>


More information about the Libraries mailing list