Proposal to solve the `EitherT` problem.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Proposal to solve the `EitherT` problem.

Gabriel Gonzalez
As an application writer I'm a big fan of Edward's `either` package
because his `EitherT` does not require an `Error` constraint.  As a
library writer, I am wary of heavy dependencies and I would prefer
something more light-weight that I can depend on.

Normally I would just directly contact Edward about reducing the number
of dependencies but there was a previous discussion here about possibly
merging his work into `transformers`, so I'm renewing that discussion
and bringing up a few approaches for consideration.

There are three approaches that I'd like to submit for consideration and
receive feedback on:

* Approach 1: Remove the `Error` constraint from `transformers`

Disadvantage: This silently breaks all existing uses of `fail`.  I don't
know any way to add a compiler warning to notify downstream libraries of
this change.

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

Disadvantage: Bloat from having two almost identical monad
transformers.  However, there is precedent from duplicating `StateT`,
`WriterT` and `RWST` for both strict and lazy instances.

* Approach 3: Convince Edward to reduce the dependencies of the `either`
package and submit the simplified version to the Haskell platform.

Disadvantage: One extra import instead of just importing `transformers`.

* Approach 4: None of the above.

Disadvantage: Packages that depend on `either` have very low prospects
of making it into the Haskell platform.

If you have time, just take a moment to vote on which approach you favor
or propose another alternative if you have another idea that I haven't
listed.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann

On Sun, 16 Jun 2013, Gabriel Gonzalez wrote:

> There are three approaches that I'd like to submit for consideration and
> receive feedback on:
>
> * Approach 1: Remove the `Error` constraint from `transformers`
>
> Disadvantage: This silently breaks all existing uses of `fail`.  I don't know
> any way to add a compiler warning to notify downstream libraries of this
> change.
>
> * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and have
> them both implement `MonadError`.
>
> Disadvantage: Bloat from having two almost identical monad transformers.
> However, there is precedent from duplicating `StateT`, `WriterT` and `RWST`
> for both strict and lazy instances.

I prefer this one. Additionally one might deprecate ErrorT.

Btw. MaybeT also went into transformers although there was already a
MaybeT package.


> * Approach 3: Convince Edward to reduce the dependencies of the `either`
> package and submit the simplified version to the Haskell platform.
>
> Disadvantage: One extra import instead of just importing `transformers`.
>
> * Approach 4: None of the above.
>
> Disadvantage: Packages that depend on `either` have very low prospects of
> making it into the Haskell platform.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Roman Cheplyaka-2
In reply to this post by Gabriel Gonzalez
* Gabriel Gonzalez <[hidden email]> [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.html

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

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

> * Gabriel Gonzalez<[hidden email]>  [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.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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
In reply to this post by Gabriel Gonzalez
On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
> There are three approaches that I'd like to submit for consideration
> and receive feedback on:
>
> * Approach 1: Remove the `Error` constraint from `transformers`
>
> Disadvantage: This silently breaks all existing uses of `fail`.  I
> don't know any way to add a compiler warning to notify downstream
> libraries of this change.

I'm in favour of this one.  We can catch some of these uses by deprecating
the Error class, as the only predefined instances are for IOException
and String.

> * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and
> have them both implement `MonadError`.
>
> Disadvantage: Bloat from having two almost identical monad
> transformers.  However, there is precedent from duplicating
> `StateT`, `WriterT` and `RWST` for both strict and lazy instances.

Those is at least a rationale for two StateT transformers with strict
and lazy instances.  (Since the strict WriterT doesn't achieve its aim,
I'm in favour of deprecating it, and the strict RWST.)

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Edward Kmett-2
In reply to this post by Gabriel Gonzalez
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 <[hidden email]> wrote:
On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:
* Gabriel Gonzalez<[hidden email]>  [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.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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Dan Burton
In reply to this post by Gabriel Gonzalez
+1

This is in the same spirit as the missing Traversable & friends instances for Either: this is what Haskellers are coming to expect as standard.

-- Dan Burton


On Sun, Jun 16, 2013 at 3:12 PM, Gabriel Gonzalez <[hidden email]> wrote:
On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:
* Gabriel Gonzalez<[hidden email]>  [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.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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Gabriel Gonzalez
In reply to this post by Gabriel Gonzalez
On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
> There are three approaches that I'd like to submit for consideration
> and receive feedback on:
>
> * Approach 1: Remove the `Error` constraint from `transformers`
>
> Disadvantage: This silently breaks all existing uses of `fail`.  I
> don't know any way to add a compiler warning to notify downstream
> libraries of this change.
I'm in favour of this one.  We can catch some of these uses by deprecating
the Error class, as the only predefined instances are for IOException
and String.

I'm going to add another disadvantage of this approach: `ErrorT` is not as good of a name.  `EitherT` is a more neutral name, which matters if you want to use it for non-error-based flow control like the way I describe here:

 

> * Approach 2: Add `EitherT` to `transformers` alongside `ErrorT` and
> have them both implement `MonadError`.
>
> Disadvantage: Bloat from having two almost identical monad
> transformers.  However, there is precedent from duplicating
> `StateT`, `WriterT` and `RWST` for both strict and lazy instances.
Those is at least a rationale for two StateT transformers with strict
and lazy instances.  (Since the strict WriterT doesn't achieve its aim,
I'm in favour of deprecating it, and the strict RWST.)

The nice thing about Approach 2 is that it is backwards compatible for now and gives downstream libraries a chance to gracefully transition to `EitherT` if you decide to deprecate `ErrorT`.  This works out better than usual because the names are different so they can peacefully coexist for one release.

However, you might still want to keep `ErrorT` around as long as `fail` is still part of the `Monad` class.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
On Mon, Jun 17, 2013 at 11:27:18AM -0700, Gabriel Gonzalez wrote:

>     On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
>     > There are three approaches that I'd like to submit for consideration
>     > and receive feedback on:
>     >
>     > * Approach 1: Remove the `Error` constraint from `transformers`
>     >
>     > Disadvantage: This silently breaks all existing uses of `fail`.  I
>     > don't know any way to add a compiler warning to notify downstream
>     > libraries of this change.
>
> I'm going to add another disadvantage of this approach: `ErrorT`
> is not as good of a name.  `EitherT` is a more neutral name, which
> matters if you want to use it for non-error-based flow control like
> the way I describe here:
>
> http://www.haskellforall.com/2012/07/breaking-from-loop.html

Fair point, but then EitherT is too neutral, giving no hint of the purpose
of the monad instance, and suggesting a symmetry that is absent from the
monad: Right is normal monadic sequencing, while Left is the exceptional
control path.  Things get particularly 'sinister' when you get to naming
the throw and catch combinators.  It's a bit like the reason for having
Writer instead of using the monad instance for (,).  So I'd lean more to
something like Except, which would also be in line with Moggi's original
presentation of this monat and transformer.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann

On Mon, 17 Jun 2013, Ross Paterson wrote:

> On Mon, Jun 17, 2013 at 11:27:18AM -0700, Gabriel Gonzalez wrote:
>>     On Sun, Jun 16, 2013 at 02:52:46PM -0700, Gabriel Gonzalez wrote:
>>    > There are three approaches that I'd like to submit for consideration
>>    > and receive feedback on:
>>    >
>>    > * Approach 1: Remove the `Error` constraint from `transformers`
>>    >
>>    > Disadvantage: This silently breaks all existing uses of `fail`.  I
>>    > don't know any way to add a compiler warning to notify downstream
>>    > libraries of this change.
>>
>> I'm going to add another disadvantage of this approach: `ErrorT`
>> is not as good of a name.  `EitherT` is a more neutral name, which
>> matters if you want to use it for non-error-based flow control like
>> the way I describe here:
>>
>> http://www.haskellforall.com/2012/07/breaking-from-loop.html
>
> Fair point, but then EitherT is too neutral, giving no hint of the purpose
> of the monad instance, and suggesting a symmetry that is absent from the
> monad: Right is normal monadic sequencing, while Left is the exceptional
> control path.  Things get particularly 'sinister' when you get to naming
> the throw and catch combinators.  It's a bit like the reason for having
> Writer instead of using the monad instance for (,).  So I'd lean more to
> something like Except, which would also be in line with Moggi's original
> presentation of this monat and transformer.

  I also think that the monad instances on Either and (,) are abuses. (And
the monad instance on (->), too, since once I got a hard to find error
where a missing argument in a function call was interpreted as an instance
of the Reader monad.)
  Thus I think EitherT is not a good name, and I would also prefer
something containing "except".

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Gabriel Gonzalez
In reply to this post by Gabriel Gonzalez
Fair point, but then EitherT is too neutral, giving no hint of the purpose
of the monad instance, and suggesting a symmetry that is absent from the
monad: Right is normal monadic sequencing, while Left is the exceptional
control path.  Things get particularly 'sinister' when you get to naming
the throw and catch combinators.  It's a bit like the reason for having
Writer instead of using the monad instance for (,).  So I'd lean more to
something like Except, which would also be in line with Moggi's original
presentation of this monat and transformer.

However, there is prior art (i.e. the existing name of `Either`).  Using a different name for the monad and the monad transformer seems like bad form to me.

This is also a good argument for keeping both monad transformers in `transformers`.  `ErrorT` satisfies the people who want a meaningful name and `EitherT` satisfies the people who prefer a neutral purpose.

 I also think that the monad instances on Either and (,) are abuses. (And
the monad instance on (->), too, since once I got a hard to find error
where a missing argument in a function call was interpreted as an instance
of the Reader monad.)

I think that this position is too extreme.  The use of the `Either` monad for error handling is Haskell canon and is more widely understood than even monad transformers.  The logical conclusion of what you are proposing is to duplicate all `Either` machinery once for each potential application of `Either`.

That's not to say that there shouldn't be isomorphic types with names and behaviors tailored to specific application domains.  I understand the perils of "boolean blindness" (and its equivalent for other types).  However, there needs to be space in the standard libraries for the neutral approach otherwise you will fragment the library ecosystem considerably.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
On Mon, Jun 17, 2013 at 01:14:23PM -0700, Gabriel Gonzalez wrote:

>     Fair point, but then EitherT is too neutral, giving no hint of the purpose
>     of the monad instance, and suggesting a symmetry that is absent from the
>     monad: Right is normal monadic sequencing, while Left is the exceptional
>     control path.  Things get particularly 'sinister' when you get to naming
>     the throw and catch combinators.  It's a bit like the reason for having
>     Writer instead of using the monad instance for (,).  So I'd lean more to
>     something like Except, which would also be in line with Moggi's original
>     presentation of this monat and transformer.
>
> However, there is prior art (i.e. the existing name of `Either`).
> Using a different name for the monad and the monad transformer seems
> like bad form to me.

Indeed having a differents name for the monad and monad transformer was
always another of the flaws of ErrorT, but there's another way to fix
that, and more in line with the treatment of the other monad transformers
(with the exception of MaybeT).

> This is also a good argument for keeping both monad transformers in
> `transformers`.  `ErrorT` satisfies the people who want a meaningful
> name and `EitherT` satisfies the people who prefer a neutral purpose.

Actually it isn't: you've shown that the name Error is too limited and
I've shown that Either is too broad.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Jeff Shaw-2
On Tuesday, June 18, 2013 3:44:07 PM, Ross Paterson wrote:

> On Mon, Jun 17, 2013 at 01:14:23PM -0700, Gabriel Gonzalez wrote:
>>      Fair point, but then EitherT is too neutral, giving no hint of the purpose
>>      of the monad instance, and suggesting a symmetry that is absent from the
>>      monad: Right is normal monadic sequencing, while Left is the exceptional
>>      control path.  Things get particularly 'sinister' when you get to naming
>>      the throw and catch combinators.  It's a bit like the reason for having
>>      Writer instead of using the monad instance for (,).  So I'd lean more to
>>      something like Except, which would also be in line with Moggi's original
>>      presentation of this monat and transformer.
>>
>> However, there is prior art (i.e. the existing name of `Either`).
>> Using a different name for the monad and the monad transformer seems
>> like bad form to me.
>
> Indeed having a differents name for the monad and monad transformer was
> always another of the flaws of ErrorT, but there's another way to fix
> that, and more in line with the treatment of the other monad transformers
> (with the exception of MaybeT).
>
>> This is also a good argument for keeping both monad transformers in
>> `transformers`.  `ErrorT` satisfies the people who want a meaningful
>> name and `EitherT` satisfies the people who prefer a neutral purpose.
>
> Actually it isn't: you've shown that the name Error is too limited and
> I've shown that Either is too broad.
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

I found that the meaning of EitherT was completely obvious to me while
I was learning Haskell. Either is always introduced early on as a way
to return error values, and so after learning what Monad Transformers
are for, EitherT was a natural name. I found ErrorT to be useless as it
was too restrictive.

Jeff

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

David Luposchainsky
In reply to this post by Gabriel Gonzalez
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
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.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann-4
Am 13.08.2013 14:12, schrieb Ross Paterson:

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

+1


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Edward Kmett-2
In reply to this post by Ross Paterson-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Gabriel Gonzalez
In reply to this post by David Luposchainsky
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann-4
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.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123