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
|

Re: Proposal to solve the `EitherT` problem.

Ross Paterson-2
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
[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
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 <[hidden email]> 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
[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 Ross Paterson-2
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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries


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