Proposal to solve the `EitherT` problem.
Dag Odenhall
dag.odenhall at gmail.com
Tue Aug 13 22:30:50 CEST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130813/20f07734/attachment.htm>
More information about the Libraries
mailing list