Discussion:
MonadFail instance for Either
Daniel Bergey
2018-10-25 02:43:43 UTC
Permalink
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
David Feuer
2018-10-25 03:41:38 UTC
Permalink
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.
Post by Daniel Bergey
Is there still consensus in favor of adding this instance?
instance IsString str => MonadFail (Either str) where
fail = Left . fromString
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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Dannyu NDos
2018-10-25 03:50:50 UTC
Permalink
What about?:

instance Read e => MonadFail (Either e) where
fail = Left . read
Post by 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.
Post by Daniel Bergey
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
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it simply no
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more discussion
in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
David Feuer
2018-10-25 03:52:49 UTC
Permalink
No, that's awful. You'd need to write things like

fail "\"my mistake\""
Post by Dannyu NDos
instance Read e => MonadFail (Either e) where
fail = Left . read
Post by 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.
Post by Daniel Bergey
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
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it simply no
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-25 07:05:45 UTC
Permalink
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
Post by 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.
Post by Daniel Bergey
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
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it simply no
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more discussion
in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
David Feuer
2018-10-25 07:21:51 UTC
Permalink
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.
Post by Edward Kmett
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
Post by 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.
Post by Daniel Bergey
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
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it simply no
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Bergey
2018-10-25 11:48:44 UTC
Permalink
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.
Post by David Feuer
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.
Post by Edward Kmett
I'm also weakly inclined against it.
If we decided we really wanted something, then building a class that
was
Post by Edward Kmett
just for this purpose might work, sort of an updated version of the
old
Post by Edward Kmett
'Error' class from transformers, but now limited to just the failure
string
Post by Edward Kmett
so it has no extra baggage.
On the other hand, that then faces inertia problems all its own.
-Edward
Post by 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
Post by Edward Kmett
Post by David Feuer
meaningful
at the moment. IsString ... isn't.
Post by Daniel Bergey
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
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it
simply no
Post by Edward Kmett
Post by David Feuer
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Bergey
2018-10-25 12:06:03 UTC
Permalink
I meant something like

foo :: MonadFail m => A -> m Foo

Sorry if my first version without input caused confusion.
Post by Daniel Bergey
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.
Post by David Feuer
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.
Post by Edward Kmett
I'm also weakly inclined against it.
If we decided we really wanted something, then building a class that
was
Post by Edward Kmett
just for this purpose might work, sort of an updated version of the
old
Post by Edward Kmett
'Error' class from transformers, but now limited to just the failure
string
Post by Edward Kmett
so it has no extra baggage.
On the other hand, that then faces inertia problems all its own.
-Edward
Post by David Feuer
FWIW, I think I'm weakly opposed. Either is Haskell 98. MonadFail
is
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
solidly "standards-track" material, to the extent that designation
is
Post by Edward Kmett
Post by David Feuer
meaningful
at the moment. IsString ... isn't.
On Wed, Oct 24, 2018 at 10:44 PM Daniel Bergey
Post by Daniel Bergey
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
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it
simply no
Post by Edward Kmett
Post by David Feuer
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett
2018-10-25 13:45:40 UTC
Permalink
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
Post by Daniel Bergey
I meant something like
foo :: MonadFail m => A -> m Foo
Sorry if my first version without input caused confusion.
Post by Daniel Bergey
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.
Post by David Feuer
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.
Post by Edward Kmett
I'm also weakly inclined against it.
If we decided we really wanted something, then building a class that
was
Post by Edward Kmett
just for this purpose might work, sort of an updated version of the
old
Post by Edward Kmett
'Error' class from transformers, but now limited to just the failure
string
Post by Edward Kmett
so it has no extra baggage.
On the other hand, that then faces inertia problems all its own.
-Edward
Post by David Feuer
FWIW, I think I'm weakly opposed. Either is Haskell 98. MonadFail
is
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
solidly "standards-track" material, to the extent that designation
is
Post by Edward Kmett
Post by David Feuer
meaningful
at the moment. IsString ... isn't.
On Wed, Oct 24, 2018 at 10:44 PM Daniel Bergey
Post by Daniel Bergey
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
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it
simply no
Post by Edward Kmett
Post by David Feuer
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Daniel Bergey
2018-10-25 18:04:54 UTC
Permalink
I updated trac to reflect this discussion.
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
Post by Daniel Bergey
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
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
Post by Daniel Bergey
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
Post by David Feuer
instance MonadFail (Either [Char]) where
fail = Left
That'll work today, and leave the question of the ultimate
constraint
Post by Daniel Bergey
Post by David Feuer
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.
Post by Edward Kmett
I'm also weakly inclined against it.
If we decided we really wanted something, then building a class
that
Post by Daniel Bergey
Post by David Feuer
was
Post by Edward Kmett
just for this purpose might work, sort of an updated version of
the
Post by Daniel Bergey
Post by David Feuer
old
Post by Edward Kmett
'Error' class from transformers, but now limited to just the
failure
Post by Daniel Bergey
Post by David Feuer
string
Post by Edward Kmett
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
Post by David Feuer
FWIW, I think I'm weakly opposed. Either is Haskell 98. MonadFail
is
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
solidly "standards-track" material, to the extent that
designation
Post by Daniel Bergey
Post by David Feuer
is
Post by Edward Kmett
Post by David Feuer
meaningful
at the moment. IsString ... isn't.
On Wed, Oct 24, 2018 at 10:44 PM Daniel Bergey
Post by Daniel Bergey
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
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Trac: https://ghc.haskell.org/trac/ghc/ticket/12160
https://mail.haskell.org/pipermail/libraries/2016-August/027248.html
Post by David Feuer
Post by Edward Kmett
Post by David Feuer
Post by Daniel Bergey
Does anyone know of a later decision not to add it, or was it
simply no
Post by Edward Kmett
Post by David Feuer
one's top priority?
Post by Daniel Bergey
What is the next step to move this proposal forward? Is more
discussion in order? Should I just submit a patch?
Post by Daniel Bergey
Thanks,
bergey
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...