Gabriel Gonzalez | 16 Jun 23:52 2013
Picon

Proposal to solve the `EitherT` problem.

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`.
(Continue reading)

Henning Thielemann | 16 Jun 23:59 2013
Picon

Re: Proposal to solve the `EitherT` problem.


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.
(Continue reading)

Roman Cheplyaka | 17 Jun 00:09 2013

Re: Proposal to solve the `EitherT` problem.

* Gabriel Gonzalez <gabriel439 <at> gmail.com> [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
Gabriel Gonzalez | 17 Jun 00:12 2013
Picon

Re: Proposal to solve the `EitherT` problem.

On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:
> * Gabriel Gonzalez<gabriel439 <at> gmail.com>  [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.
Edward Kmett | 17 Jun 18:19 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <gabriel439 <at> gmail.com> wrote:
On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:
* Gabriel Gonzalez<gabriel439 <at> gmail.com>  [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
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dan Burton | 17 Jun 19:50 2013
Picon

Re: Proposal to solve the `EitherT` problem.

+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 <gabriel439 <at> gmail.com> wrote:
On 06/16/2013 03:09 PM, Roman Cheplyaka wrote:
* Gabriel Gonzalez<gabriel439 <at> gmail.com>  [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
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 17 Jun 02:32 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.)
Gabriel Gonzalez | 17 Jun 20:27 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 17 Jun 21:24 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Henning Thielemann | 17 Jun 21:36 2013
Picon

Re: Proposal to solve the `EitherT` problem.


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".
Gabriel Gonzalez | 17 Jun 22:14 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 18 Jun 21:44 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Jeff Shaw | 19 Jun 04:17 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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
> Libraries <at> haskell.org
> 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
David Luposchainsky | 13 Aug 10:36 2013

Re: Proposal to solve the `EitherT` problem.

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
Ross Paterson | 13 Aug 14:12 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Henning Thielemann | 13 Aug 16:24 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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
Edward Kmett | 13 Aug 16:30 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <R.Paterson <at> city.ac.uk> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 13 Aug 19:25 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Edward Kmett | 13 Aug 22:39 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <R.Paterson <at> city.ac.uk> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dag Odenhall | 13 Aug 22:43 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <ekmett <at> gmail.com> 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 <R.Paterson <at> city.ac.uk> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
MightyByte | 13 Aug 23:18 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <dag.odenhall <at> gmail.com> 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 <ekmett <at> gmail.com> 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 <R.Paterson <at> city.ac.uk>
>> 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 <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
John Wiegley | 13 Aug 23:34 2013

Re: Proposal to solve the `EitherT` problem.

>>>>> MightyByte  <mightybyte <at> gmail.com> 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.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net
Henning Thielemann | 14 Aug 11:20 2013
Picon

List monad (Re: Proposal to solve the `EitherT` problem.)

Am 13.08.2013 23:34, schrieb John Wiegley:
>>>>>> MightyByte  <mightybyte <at> gmail.com> 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.
Henning Thielemann | 14 Aug 10:56 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.

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.
Gabriel Gonzalez | 14 Aug 17:03 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Edward A Kmett | 14 Aug 00:57 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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

Sent from my iPhone

On Aug 13, 2013, at 1:25 PM, Ross Paterson <R.Paterson <at> city.ac.uk> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Daniel Trstenjak | 14 Aug 09:42 2013
Picon

Re: Proposal to solve the `EitherT` problem.


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
Henning Thielemann | 14 Aug 11:22 2013
Picon

Re: Proposal to solve the `EitherT` problem.

Am 14.08.2013 09:42, schrieb Daniel Trstenjak:
>
> 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?

I also think that Maybe so far is consistently used for exception 
handling without exception information. Thus I am fine with MaybeT.
Gabriel Gonzalez | 14 Aug 16:50 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Edward Kmett | 14 Aug 16:51 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 14 Aug 17:43 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________ Libraries mailing list Libraries <at> haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Bardur Arantsson | 14 Aug 19:01 2013
Picon

Re: Proposal to solve the `EitherT` problem.

On 2013-08-14 17:43, 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.
> 

+1 all the way.
Dan Burton | 14 Aug 19:14 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <gabriel439 <at> gmail.com> 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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________ Libraries mailing list Libraries <at> haskell.org http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dan Burton | 14 Aug 19:15 2013
Picon

Re: Proposal to solve the `EitherT` problem.

Whoops I got the "code" wrong for ExceptionT, but you get the idea.

-- Dan Burton


On Wed, Aug 14, 2013 at 10:14 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
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 <gabriel439 <at> gmail.com> 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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________ Libraries mailing list Libraries <at> haskell.org http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Gábor Lehel | 15 Aug 01:03 2013
Picon

Re: Proposal to solve the `EitherT` problem.

+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 <gabriel439 <at> gmail.com> 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 <at> 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 <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--

-- 
Your ship was destroyed in a monadic eruption.
John Lato | 15 Aug 01:30 2013
Picon

Re: Proposal to solve the `EitherT` problem.

Edward already pointed this out, however it seems to me that most commenters on this thread are neglecting one salient point: transformers is Ross's package.  I don't think anyone is presenting any new arguments at this point, simply rehashing their support for one stance or another.  Given that, this appears to be devolving into "everyone respond on thread until Ross caves," which I think is a bad precedent.


On Wed, Aug 14, 2013 at 6:03 PM, Gábor Lehel <illissius <at> gmail.com> wrote:
+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 <gabriel439 <at> gmail.com> 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 <at> 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 <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Your ship was destroyed in a monadic eruption.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ross Paterson | 15 Aug 16:50 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
Edward Kmett | 15 Aug 17:20 2013
Picon

Re: Proposal to solve the `EitherT` problem.

And yet, because many of the users of the library are just using Either, both will still probably have to exist anyways unless Gabriel also wants to raise a similar hue and cry. 

My experience from talking to folks is that they start using errors with Either and then upgrade to EitherT since they already know how to use the basic combinators. The loss of that pedagogical vector to adoption would be a rather big blow to the adoption of the package.

The nature of those combinators is that people use them to reduce the noise in their code. EitherT e Identity is noisier than Either to pattern match on and work with when you're done tossing code through errors combinators.

-Edward


On Thu, Aug 15, 2013 at 10:50 AM, Ross Paterson <R.Paterson <at> city.ac.uk> 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.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 15 Aug 20:09 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 13 Aug 20:31 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 13 Aug 22:09 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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.
David Virebayre | 14 Aug 11:14 2013
Picon

Re: Proposal to solve the `EitherT` problem.

2013/8/13 Henning Thielemann <schlepptop <at> henning-thielemann.de>:
> 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.

I find Henning Thielemann and Ross Paterson's arguments very convicing too.
Dag Odenhall | 13 Aug 22:30 2013
Picon

Re: Proposal to solve the `EitherT` problem.

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 <gabriel439 <at> gmail.com> 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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane