If EitherT merged into transformers, I'd happily just move the instance into the semigroup and semigroupoid packages respectively. On Sun, Jun 16, 2013 at 6:12 PM, Gabriel Gonzalez wrote:

On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:

...

* Gabriel Gonzalez [2013-06-16 14:52:46-0700]

...

* Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have them both implement `MonadError`.

I already submitted the proposal to merge EitherT into transformers [1], which enjoyed universal support, barring some implementation details.

So why not just bring that proposal to its conclusion?

[1]: http://www.haskell.org/**pipermail/libraries/2012-** December/019027.htmlhttp://www.haskell.org/pipermail/libraries/2012-December/019027.html

Roman

Thanks for reminding me of this. I vaguely remembered this but couldn't find the thread.

I'll gladly get behind your original proposal, then. I particularly liked the suggestion of keeping the `either` package around to provide the `semigroups` and `semigroupoids` instances.

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

On Tue, Aug 13, 2013 at 10:36:16AM +0200, David Luposchainsky wrote:

Another discussion that didn't reach conclusion: "Proposal to solve the `EitherT` problem." Let's do some proposal cleanup :-)

On 2013-06-16 23:52, Gabriel Gonzalez wrote:

...

Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have them both implement `MonadError`.

That's the one I would recommend.

- Doesn't break anything, and gets rid of the "exception-vs-error" discussion.

- Not all uses of Either are to distinguish between success and failure, sometimes it's just a convenient way of short-circuiting.

- Fits in well with all the other transformers of type "MonadT".

- MonadError instance makes possible use as throw-catch-y transformer clear.

My preference is to call the new transformer ExceptT, with a basic monad called Except, in line with most of the other transformers, and to deprecate ErrorT. (The rationale for the name is that Either isn't just for exceptions, and exceptions aren't just for errors.) I'm a bit unsure about the MonadPlus/Alternative instance. The exception type needs a default element to implement mzero, which the EitherT implementation obtains with a Monoid constraint, and then has mplus collecting exceptions. This could give surprising behaviour if your exception type is String, say.

An argument against just randomly bikeshedding the name it is there are a lot of packages out there currently transitively depending on the existing either package, due to the popularity of Tekmo's errors package and the fact that it has been picked up by snap. So half of the web-apps in the ecosystem depend on this type transitively. Renaming it means that folks have to make a sharp cut-off in support, and there are folks out there like the snap community, who use the current version and support 3 major versions of GHC and all attendant platforms. EitherT is literally the coproduct of the Either monad and any other monad, made possible by fact that Either is ideal and so can commute, so in essence EitherT is the most 'free' construction involving Either, while ErrorT is the special case. -Edward On Tue, Aug 13, 2013 at 8:12 AM, Ross Paterson wrote:

On Tue, Aug 13, 2013 at 10:36:16AM +0200, David Luposchainsky wrote:

...

Another discussion that didn't reach conclusion: "Proposal to solve the `EitherT` problem." Let's do some proposal cleanup :-)

On 2013-06-16 23:52, Gabriel Gonzalez wrote:

...

Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have them both implement `MonadError`.

That's the one I would recommend.

- Doesn't break anything, and gets rid of the "exception-vs-error" discussion.

- Not all uses of Either are to distinguish between success and failure, sometimes it's just a convenient way of short-circuiting.

- Fits in well with all the other transformers of type "MonadT".

- MonadError instance makes possible use as throw-catch-y transformer clear.

My preference is to call the new transformer ExceptT, with a basic monad called Except, in line with most of the other transformers, and to deprecate ErrorT. (The rationale for the name is that Either isn't just for exceptions, and exceptions aren't just for errors.)

I'm a bit unsure about the MonadPlus/Alternative instance. The exception

type needs a default element to implement mzero, which the EitherT implementation obtains with a Monoid constraint, and then has mplus collecting exceptions. This could give surprising behaviour if your exception type is String, say.

Haven't we managed to work out that there isn't a way to collect exceptions in the left hand side of Either that also forms a Monad? I recall this discussion coming up almost every time someone makes an Either/EitherT like monad like \/ or validation in scalaz, because the kneejerk is to try to accumulate errors in the Applicative, leading to an issue when you compare it to the Monad. -Edward

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Did you consider the transitive dependency from errors? Errors re-exports Control.Monad.Trans.Either from Control.Error. In particular I noted that snap then depends on errors. I didn't grep through the source though. -Edward On Tue, Aug 13, 2013 at 1:25 PM, Ross Paterson wrote:

On Tue, Aug 13, 2013 at 10:30:23AM -0400, Edward Kmett wrote:

...

An argument against just randomly bikeshedding the name it is there are a lot of packages out there currently transitively depending on the existing either package, due to the popularity of Tekmo's errors package and the fact that it has been picked up by snap. So half of the web-apps in the ecosystem depend on this type transitively.

Fortunately it seems that EitherT is only used by the following packages:

citation-resolve coroutine-object CSPM-Frontend errors happstack-heist hoodle-core hoodle-parser katt pdf-toolbox-core pianola restricted-workers terminfo-hs

Moreover adding a new module and type means people can switch over an extended timescale. Thus I think internal consistency within transformers outweighs compatibility with the existing EitherT in this case.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

For me, the name EitherT wins by a large margin. Way back when I first learned about MaybeT, it totally rocked my world. I had been plagued for quite some time by the problems that MaybeT addresses but didn't know of the solution. I had already seen things like ReaderT and StateT, but for some reason I hadn't yet made the connection to how the idea would carry over to the Maybe monad. After I learned about MaybeT, EitherT was the natural name I expected. If EitherT had been in transformers, I think I would have used it even sooner. I think the discoverability of the name EitherT is huge win given the existing conventions. I think I had even seen ErrorT before MaybeT, but the name obscured its significance for me. Also, as Ed pointed out, I do use the errors package in snap. These days I use errors in pretty much every substantial project I work on. Usually that includes EitherT, so renaming it would impose a huge cost. On Tue, Aug 13, 2013 at 4:43 PM, Dag Odenhall wrote:

Also, grepping hackage is all well and good but that‘s ignoring all the code that’s either not released yet or is closed source. That's probably the case with a lot of application code, with hackage having mostly libraries. Just a thought.

On Tue, Aug 13, 2013 at 10:39 PM, Edward Kmett wrote:

...

Did you consider the transitive dependency from errors?

Errors re-exports Control.Monad.Trans.Either from Control.Error.

In particular I noted that snap then depends on errors.

I didn't grep through the source though.

-Edward

On Tue, Aug 13, 2013 at 1:25 PM, Ross Paterson wrote:

...

On Tue, Aug 13, 2013 at 10:30:23AM -0400, Edward Kmett wrote:

...

An argument against just randomly bikeshedding the name it is there are a lot of packages out there currently transitively depending on the existing either package, due to the popularity of Tekmo's errors package and the fact that it has been picked up by snap. So half of the web-apps in the ecosystem depend on this type transitively.

Fortunately it seems that EitherT is only used by the following packages:

citation-resolve coroutine-object CSPM-Frontend errors happstack-heist hoodle-core hoodle-parser katt pdf-toolbox-core pianola restricted-workers terminfo-hs

Moreover adding a new module and type means people can switch over an extended timescale. Thus I think internal consistency within transformers outweighs compatibility with the existing EitherT in this case.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am 13.08.2013 23:34, schrieb John Wiegley:

...

...

...

...

...

MightyByte writes:

...

I think the discoverability of the name EitherT is huge win given the existing conventions. I think I had even seen ErrorT before MaybeT, but the name obscured its significance for me.

I agree strongly with this point. EitherT is a natural fit in the ecosystem of MaybeT, ListT, etc.

To extend my list of abuses: For me the default monad instance for list is also unfortunate. The monad instance for lists is about combinatorial programming, others call it non-deterministic programming. But why? It somehow imposes a duty to define a similar instances for similar data structures like Streams. But the monad list instance makes no sense on Streams. On streams you would need a diagonal order of elements. The Monad list instance must be consistent with the Applicative instance. There are much more types that allow for an Applicative instance. Now you are constantly in trouble: If you define a list-like type like Sequence or NonEmptyList you must think about its possible Monad and Applicative instances. If there is a Monad instance you are somehow pushed to make it consistent with the combinatorial Monad List instance. For a ZipList semantics you must use wrapper then. In contrast to that, if there cannot be such a Monad instance, you will certainly define the Applicative instance in a ZipList way instead of omitting the Applicative instance. However, whatever you choose you will be inconsistent with some of the other instances. This confirms my distinctions between mathematical soundness and practical uses: The List type allows multiple mathematically sound Applicative instances. But for deciding on the instance we need to look at the use of the type. If I could redesign Prelude I would define "instance Applicative []" with a ZipList semantics and I would omit the Monad instance. For the combinatorial programming I would define a newtype wrapper around "[]". This way I could define different wrapper types for different element orderings. No ordering would be privileged.

On 08/14/2013 01:56 AM, Henning Thielemann wrote:

Am 13.08.2013 23:18, schrieb MightyByte:

...

For me, the name EitherT wins by a large margin. Way back when I first learned about MaybeT, it totally rocked my world. I had been plagued for quite some time by the problems that MaybeT addresses but didn't know of the solution. I had already seen things like ReaderT and StateT, but for some reason I hadn't yet made the connection to how the idea would carry over to the Maybe monad. After I learned about MaybeT, EitherT was the natural name I expected. If EitherT had been in transformers, I think I would have used it even sooner.

I think the discoverability of the name EitherT is huge win given the existing conventions. I think I had even seen ErrorT before MaybeT, but the name obscured its significance for me.

1. You discovered Either as a monad first, which I think is the initial problem. Either should never have been abused for exception handling and it should never have been a monad. If Either would not be a monad then no-one would look for EitherT.

If you care about this so much you are free to define your own `Either` alternative without a `Monad` instance. You can call it `Union` and release it in a `union` package and program with it all you want. However, I don't support this notion of fragmenting the ecosystem in search of the perfect nomenclature when the `Either` one has served us so well for so long. This whole `ExceptT` thing sounds like a solution in search of a problem. I've never heard of somebody that got bitten by `Either` having a `Monad` instance. While we're at it, why don't we remove the default `Num` instance for `Integer`s? I have some project where I use numbers as labels and addition breaks the type safety of my labels, therefore the `Num` instance is an abuse of `Integer`s. That might sound ridiculous because I can *obviously* newtype `Integer`s to remove the `Num` instance for `Integer`s, just like you can obviously newtype `Either` to remove the `Monad` instance if you really feel strongly that it's an abuse within the context of your project. However, I think most people will agree that the appropriate default should be supply a `Monad` instance and opt out as necessary, rather than opt in.

2. Now since Either is a monad and people are looking for EitherT, it would be simple to note that in the documentation of ExceptT. One could even upload a new version of "EitherT" and "either" packages that redirects people to ExceptT.

We don't want to use `EitherT` solely for error handling. There are other legitimate uses of an `Either` monad other than error handling, like short-circuiting, which is why it does not make sense to link those packages to `ExceptT`. I can't tell you how many times the `EitherT` `Monad` and `Alternative` instances have done the right thing in contexts that have nothing to do with errors, such as in conjunction with the `lens` package. The people in favor of `ExceptT` have a very narrow view that the only legitimate use of the `Monad` instance is error handling, which is simply not true.

On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:

I look forward to finding out the new name for MaybeT then. ;)

That's a bit unfair, because the Maybe data type has a clear meaning which also holds for its Monad instance. That's not the case for Either. The Either data type doesn't propose a special meaning to the 'Left' or 'Right' case, but the Monad instance of Either does. Isn't just having a discussion about such a contradiction at the end the reason why Haskell is the language it is? Greetings, Daniel

On 08/14/2013 12:42 AM, Daniel Trstenjak wrote:

On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:

...

I look forward to finding out the new name for MaybeT then. ;) That's a bit unfair, because the Maybe data type has a clear meaning which also holds for its Monad instance.

What is the distinction? For me, `Maybe` is as language-neutral as `Either`. It simply augments a value with an additional state with no connotation of error handling. If you were really trying to be consistent, you would rename `MaybeT` to `FailableT` and remove the `Monad` instance from `Maybe`.

That's not the case for Either. The Either data type doesn't propose a special meaning to the 'Left' or 'Right' case, but the Monad instance of Either does.

No, it does not have a special meaning. Bot the `Either` and `Maybe` monads are also used for short-circuiting. See here: http://www.haskellforall.com/2012/07/breaking-from-loop.html This isn't hypothetical: I do this all the time in my programming. By your logic, I should remove the `Monad` instance for `Maybe` because it's unclear in my code whether I'm using it in its capacity for error handling or for general-purpose short-circuiting.

I echo Edward's sentiments. If you disagree with Edward's design choices then you should vote with your code instead of your +1's by building and actively maintaining libraries that uphold your design principles. I see all these hypothetical arguments that `Either` might cause somebody to accidentally use its monad instance once, ever, but let's consult the facts: * Nobody here has even lifted a finger to write up a library with this hypothetical alternative to the `Either` without the `Monad` instance. This signals to me that the people arguing for removing the `Monad` instance don't actually care about this as much about this as they say they do. * Nobody has ever come onto Haskell cafe, Stack Overflow, or /r/haskell and asked: "Where can I find an `Either` without the `Monad` instance?" This signals to me that most Haskell programmers don't actually want this "feature" as much as you say they do. * Lots of Haskell programmers use Either and EitherT fluently for error handling without any confusion or programming mistakes. My `errors` library is proof of that: http://packdeps.haskellers.com/reverse/errors The reason Edward's libraries are popular and so widely used is because they solve an *actual* need, not a hypothetical need. On 08/14/2013 07:51 AM, Edward Kmett wrote:

Like Maybe, Either has perfectly unambiguous semantics as a Monad as well.

It is only when you muddle the waters with this fail nonsense that you need to choose between the Either monad and the Error monad. Error and Either would be indistinguishable otherwise.

Re: unfair. I tried to take the sting out of it with a ";)" as I was really just trying to use it to indicate that the 'consistency with the rest of transformers' ship had sailed given that MaybeT exists and is within transformers.

I was trying to fire off one last shot across the bow that in the big 2.0 switch there was a move to make "State s" be "StateT s Identity" that was mostly argued for code reuse and simplification reasons, that it cut code duplication by a factor of 2 in the body of transformers and the mtl and reduced the chance for human error.

The fact that State s = StateT s Identity rather than merely being isomorphic seems to me to be an emergent property of this change, not its purpose.

Ultimately, transformers is Ross's package, and the while maintainers can poll and ask questions of the community and take the temperature of the room it is fully his decision about how to move forward. Whatever he decides goes.

I'm just vociferously advocating for the least painful transition for me personally and tend to favor the "don't rebikeshed" solution over making changes for cosmetic reasons, because every single one of these "lets standardize something from one of my packages but randomly rename it" proposals induces a lot of accumulated work for me.

I have come somewhat to dread the inevitable discussion when someone pops up on the mailing list here asking to standardize something from one of my packages. It seems it inevitably loses features, gets bikeshedded or otherwise broken in such a way that creates work for me and others. I still want to help with getting things out to a larger audience, but I prefer to do so in a way that doesn't break code gratuitously, or worse force users into a choice between the old and the new. However, that is wandering quite a bit off topic.

-Edward

On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak mailto:daniel.trstenjak@gmail.com> wrote:

On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote: > I look forward to finding out the new name for MaybeT then. ;)

That's a bit unfair, because the Maybe data type has a clear meaning which also holds for its Monad instance.

That's not the case for Either. The Either data type doesn't propose a special meaning to the 'Left' or 'Right' case, but the Monad instance of Either does.

Isn't just having a discussion about such a contradiction at the end the reason why Haskell is the language it is?

Greetings, Daniel

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

There is a lot of inertia for the convention to right-bias Either in Haskell. The Monad instance on Either is not going away anytime soon, so I think it only appropriate to have "EitherT" as its natural extension into transformer-land. Now if we *also* want to have an isomorphic type, for example ExceptionT e a = Exception e | NoExceptions a, and tell people that it is best practice to use *this* for error-handling code, then I see no problem with that. You could put something in the haddocks of EitherT about how exception-based programming should really be done with ExceptionT instead. But for discoverability's sake, for consistency's sake, I think that transformers is incomplete without EitherT. The day Either loses its Monad instance, we can also throw away EitherT. -- Dan Burton On Wed, Aug 14, 2013 at 8:43 AM, Gabriel Gonzalez wrote:

I echo Edward's sentiments. If you disagree with Edward's design choices then you should vote with your code instead of your +1's by building and actively maintaining libraries that uphold your design principles.

I see all these hypothetical arguments that `Either` might cause somebody to accidentally use its monad instance once, ever, but let's consult the facts:

* Nobody here has even lifted a finger to write up a library with this hypothetical alternative to the `Either` without the `Monad` instance. This signals to me that the people arguing for removing the `Monad` instance don't actually care about this as much about this as they say they do.

* Nobody has ever come onto Haskell cafe, Stack Overflow, or /r/haskell and asked: "Where can I find an `Either` without the `Monad` instance?" This signals to me that most Haskell programmers don't actually want this "feature" as much as you say they do.

* Lots of Haskell programmers use Either and EitherT fluently for error handling without any confusion or programming mistakes. My `errors` library is proof of that:

http://packdeps.haskellers.com/reverse/errors

The reason Edward's libraries are popular and so widely used is because they solve an *actual* need, not a hypothetical need.

On 08/14/2013 07:51 AM, Edward Kmett wrote:

Like Maybe, Either has perfectly unambiguous semantics as a Monad as well.

It is only when you muddle the waters with this fail nonsense that you need to choose between the Either monad and the Error monad. Error and Either would be indistinguishable otherwise.

Re: unfair. I tried to take the sting out of it with a ";)" as I was really just trying to use it to indicate that the 'consistency with the rest of transformers' ship had sailed given that MaybeT exists and is within transformers.

I was trying to fire off one last shot across the bow that in the big 2.0 switch there was a move to make "State s" be "StateT s Identity" that was mostly argued for code reuse and simplification reasons, that it cut code duplication by a factor of 2 in the body of transformers and the mtl and reduced the chance for human error.

The fact that State s = StateT s Identity rather than merely being isomorphic seems to me to be an emergent property of this change, not its purpose.

Ultimately, transformers is Ross's package, and the while maintainers can poll and ask questions of the community and take the temperature of the room it is fully his decision about how to move forward. Whatever he decides goes.

I'm just vociferously advocating for the least painful transition for me personally and tend to favor the "don't rebikeshed" solution over making changes for cosmetic reasons, because every single one of these "lets standardize something from one of my packages but randomly rename it" proposals induces a lot of accumulated work for me.

I have come somewhat to dread the inevitable discussion when someone pops up on the mailing list here asking to standardize something from one of my packages. It seems it inevitably loses features, gets bikeshedded or otherwise broken in such a way that creates work for me and others. I still want to help with getting things out to a larger audience, but I prefer to do so in a way that doesn't break code gratuitously, or worse force users into a choice between the old and the new. However, that is wandering quite a bit off topic.

-Edward

On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:

...

On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:

...

I look forward to finding out the new name for MaybeT then. ;)

That's a bit unfair, because the Maybe data type has a clear meaning which also holds for its Monad instance.

That's not the case for Either. The Either data type doesn't propose a special meaning to the 'Left' or 'Right' case, but the Monad instance of Either does.

Isn't just having a discussion about such a contradiction at the end the reason why Haskell is the language it is?

Greetings, Daniel

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing listLibraries@haskell.orghttp://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1 also, for what little it's worth. Maybe it would've been a better idea to have separate types for "asymmetric" error handling and for "symmetric" case-splitting in the first place, but we don't, we have Either. It has a Monad instance, and people use it. These ships have sailed. Consistency, simplicity, and the path of least resistance all point to lifting EitherT into transformers as it is. Bikeshedding the Best Possible Name for a new addition is one thing, but the potential benefit of renaming here would be so slight that it doesn't remotely justify breaking peoples' existing code over it. On Wed, Aug 14, 2013 at 5:43 PM, Gabriel Gonzalez wrote:

I echo Edward's sentiments. If you disagree with Edward's design choices then you should vote with your code instead of your +1's by building and actively maintaining libraries that uphold your design principles.

I see all these hypothetical arguments that `Either` might cause somebody to accidentally use its monad instance once, ever, but let's consult the facts:

* Nobody here has even lifted a finger to write up a library with this hypothetical alternative to the `Either` without the `Monad` instance. This signals to me that the people arguing for removing the `Monad` instance don't actually care about this as much about this as they say they do.

* Nobody has ever come onto Haskell cafe, Stack Overflow, or /r/haskell and asked: "Where can I find an `Either` without the `Monad` instance?" This signals to me that most Haskell programmers don't actually want this "feature" as much as you say they do.

* Lots of Haskell programmers use Either and EitherT fluently for error handling without any confusion or programming mistakes. My `errors` library is proof of that:

http://packdeps.haskellers.com/reverse/errors

The reason Edward's libraries are popular and so widely used is because they solve an *actual* need, not a hypothetical need.

On 08/14/2013 07:51 AM, Edward Kmett wrote:

Like Maybe, Either has perfectly unambiguous semantics as a Monad as well.

It is only when you muddle the waters with this fail nonsense that you need to choose between the Either monad and the Error monad. Error and Either would be indistinguishable otherwise.

Re: unfair. I tried to take the sting out of it with a ";)" as I was really just trying to use it to indicate that the 'consistency with the rest of transformers' ship had sailed given that MaybeT exists and is within transformers.

I was trying to fire off one last shot across the bow that in the big 2.0 switch there was a move to make "State s" be "StateT s Identity" that was mostly argued for code reuse and simplification reasons, that it cut code duplication by a factor of 2 in the body of transformers and the mtl and reduced the chance for human error.

The fact that State s = StateT s Identity rather than merely being isomorphic seems to me to be an emergent property of this change, not its purpose.

Ultimately, transformers is Ross's package, and the while maintainers can poll and ask questions of the community and take the temperature of the room it is fully his decision about how to move forward. Whatever he decides goes.

I'm just vociferously advocating for the least painful transition for me personally and tend to favor the "don't rebikeshed" solution over making changes for cosmetic reasons, because every single one of these "lets standardize something from one of my packages but randomly rename it" proposals induces a lot of accumulated work for me.

I have come somewhat to dread the inevitable discussion when someone pops up on the mailing list here asking to standardize something from one of my packages. It seems it inevitably loses features, gets bikeshedded or otherwise broken in such a way that creates work for me and others. I still want to help with getting things out to a larger audience, but I prefer to do so in a way that doesn't break code gratuitously, or worse force users into a choice between the old and the new. However, that is wandering quite a bit off topic.

-Edward

On Wed, Aug 14, 2013 at 3:42 AM, Daniel Trstenjak wrote:

...

On Tue, Aug 13, 2013 at 06:57:22PM -0400, Edward A Kmett wrote:

...

I look forward to finding out the new name for MaybeT then. ;)

That's a bit unfair, because the Maybe data type has a clear meaning which also holds for its Monad instance.

That's not the case for Either. The Either data type doesn't propose a special meaning to the 'Left' or 'Right' case, but the Monad instance of Either does.

Isn't just having a discussion about such a contradiction at the end the reason why Haskell is the language it is?

Greetings, Daniel

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Your ship was destroyed in a monadic eruption.

On Wed, Aug 14, 2013 at 10:51:01AM -0400, Edward Kmett wrote:

I was trying to fire off one last shot across the bow that in the big 2.0 switch there was a move to make "State s" be "StateT s Identity" that was mostly argued for code reuse and simplification reasons, that it cut code duplication by a factor of 2 in the body of transformers and the mtl and reduced the chance for human error.

The fact that State s = StateT s Identity rather than merely being isomorphic seems to me to be an emergent property of this change, not its purpose.

I think there's still mileage in that argument. For example, the module Control.Error.Safe in the errors package has 13 functions of the form fooErr :: e -> args -> Either e r and another 13 of the form tryFoo :: Monad m => e -> args -> EitherT e m r If the recommended base exception monad were a specialization of the recommended transformer, only one set would be needed.

On 08/15/2013 07:50 AM, Ross Paterson wrote:

On Wed, Aug 14, 2013 at 10:51:01AM -0400, Edward Kmett wrote:

...

I was trying to fire off one last shot across the bow that in the big 2.0 switch there was a move to make "State s" be "StateT s Identity" that was mostly argued for code reuse and simplification reasons, that it cut code duplication by a factor of 2 in the body of transformers and the mtl and reduced the chance for human error.

The fact that State s = StateT s Identity rather than merely being isomorphic seems to me to be an emergent property of this change, not its purpose. I think there's still mileage in that argument. For example, the module Control.Error.Safe in the errors package has 13 functions of the form

fooErr :: e -> args -> Either e r

and another 13 of the form

tryFoo :: Monad m => e -> args -> EitherT e m r

If the recommended base exception monad were a specialization of the recommended transformer, only one set would be needed.

Like I said before, you can always define: type Except e = EitherT e Identity That way people who want to ignore the base monad can use `Except`. However, there is no way that I'm getting rid of the `Either` functions from `errors` even if `transformers` has `Except`. `Either` is here to stay, and people need those `Either` functions. Don't get me wrong: I use `transformers` exclusively for effects, to a fault even. However, I think `Either` is more fundamental than `transformers` and that there is no way an `Identity`-specialized `EitherT` will ever supplant the use of `Either`.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am 13.08.2013 20:31, schrieb Gabriel Gonzalez:

I'm still in favor of adding `EitherT` to `transformers` in addition to `ErrorT`. The only person who disagreed the last discussion was Ross, so it's a matter of convincing him.

I also prefer Ross' suggestion of Except/ExceptT. Using Either as a monad for me is abuse, as is defining Monad for pairs, Num for functions, Ord for complex numbers etc.

There seems to be two types of monad transformers: 1. Those written for a particular purpose, whose T-less form is just a synonym around Identity and doesn't have many uses besides as monads ( Reader, Writer, State, Cont?) 2. Those that are trivial transformer-versions of existing data types with monad instances (Maybe, List?) So it seems to me that we actually have two transformers here, ErrorT and EitherT, and that there is a confusion that ErrorT should be EitherT and should be of the second type listed above. But maybe it is useful to have an ErrorT that just happens to use Either under the hood, the same way the other “type 1” transformers are all newtypes around some more or less “incidental” type? My conclusion thus is that we should keep ErrorT as-is plus add EitherT to transformers. That‘s a +1 to Gabriel’s approach 2. On Tue, Aug 13, 2013 at 8:31 PM, Gabriel Gonzalez wrote:

I'm still in favor of adding `EitherT` to `transformers` in addition to `ErrorT`. The only person who disagreed the last discussion was Ross, so it's a matter of convincing him.

On Tue, Aug 13, 2013 at 1:36 AM, David Luposchainsky < dluposchainsky@googlemail.com> wrote:

...

Morning,

Another discussion that didn't reach conclusion: "Proposal to solve the `EitherT` problem." Let's do some proposal cleanup :-)

On 2013-06-16 23:52, Gabriel Gonzalez wrote:

...

Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have them both implement `MonadError`.

That's the one I would recommend.

- Doesn't break anything, and gets rid of the "exception-vs-error" discussion.

- Not all uses of Either are to distinguish between success and failure, sometimes it's just a convenient way of short-circuiting.

- Fits in well with all the other transformers of type "MonadT".

- MonadError instance makes possible use as throw-catch-y transformer clear.

David

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries