MonadFail instance for Either - Libraries - Haskell.org

newer
package takeover: patience

MonadFail instance for Either

older
Typo in Data.Either

Daniel Bergey

25 Oct 2018 25 Oct '18

2:43 a.m.

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

Reply

Sign in to reply online Use email software

Show replies by date

David Feuer

25 Oct 25 Oct

3:41 a.m.

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

Reply

Sign in to reply online Use email software

Dannyu NDos

3:50 a.m.

What about?: instance Read e => MonadFail (Either e) where fail = Left . read 2018년 10월 25일 (목) 오후 12:42, David Feuer 님이 작성:

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

Reply

Sign in to reply online Use email software

David Feuer

3:52 a.m.

No, that's awful. You'd need to write things like fail "\"my mistake\"" On Wed, Oct 24, 2018, 11:51 PM Dannyu NDos wrote:

What about?:

instance Read e => MonadFail (Either e) where fail = Left . read

2018년 10월 25일 (목) 오후 12:42, David Feuer 님이 작성:

...
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

Reply

Sign in to reply online Use email software

Edward Kmett

7:05 a.m.

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 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

Reply

Sign in to reply online Use email software

David Feuer

7:21 a.m.

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 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 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

Reply

Sign in to reply online Use email software

Daniel Bergey

11:48 a.m.

instance MonadFail (Either [Char]) would satisfy all of the cases where I want this instance. So would the suggestion on Trac of instance e ~ String => MonadFail (Either e) although that probably runs afoul of David's concerns about standards. How do other people consume MonadFail? Maybe I'm missing an existing solution. When a library provides a function 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 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 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 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

Reply

Sign in to reply online Use email software

Daniel Bergey

12:06 p.m.

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.

On October 25, 2018 7:21:51 AM UTC, David Feuer 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 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 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

Reply

Sign in to reply online Use email software

Edward Kmett

1:45 p.m.

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.

On October 25, 2018 7:21:51 AM UTC, David Feuer 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 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 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

Reply

Sign in to reply online Use email software

Daniel Bergey

6:04 p.m.

I updated trac to reflect this discussion. On October 25, 2018 1:45:40 PM UTC, Edward Kmett 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 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

Reply

Sign in to reply online Use email software

2533

Age (days ago)

2533

Last active (days ago)

Download

9 comments

5 participants

tags

participants (5)

Daniel Bergey
Daniel Bergey
Dannyu NDos
David Feuer
Edward Kmett