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.

Dag Odenhall

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 <[hidden email]> 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 <[hidden email]> wrote:
Morning,

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

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

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

That's the one I would recommend.

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

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

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

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



David


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



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

Re: Proposal to solve the `EitherT` problem.

Edward Kmett-2
In reply to this post by Ross Paterson-2
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 <[hidden email]> 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
[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.

Dag Odenhall

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


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

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.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> 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.

John Wiegley-3
>>>>> MightyByte  <[hidden email]> 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

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

Re: Proposal to solve the `EitherT` problem.

Edward Kmett-2
In reply to this post by Ross Paterson-2
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 <[hidden email]> 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
> [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.

Daniel Trstenjak-2

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

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann-4
In reply to this post by MightyByte
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.


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

Re: Proposal to solve the `EitherT` problem.

David Virebayre
In reply to this post by Henning Thielemann-4
2013/8/13 Henning Thielemann <[hidden email]>:
> 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.

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

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

Henning Thielemann-4
In reply to this post by John Wiegley-3
Am 13.08.2013 23:34, schrieb John Wiegley:
>>>>>> MightyByte  <[hidden email]> 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.


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

Re: Proposal to solve the `EitherT` problem.

Henning Thielemann-4
In reply to this post by Daniel Trstenjak-2
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.


_______________________________________________
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 Daniel Trstenjak-2
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.

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

Re: Proposal to solve the `EitherT` problem.

Edward Kmett-2
In reply to this post by Daniel Trstenjak-2
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 <[hidden email]> 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
[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 Henning Thielemann-4
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.

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



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

Bardur Arantsson-2
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.


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

Re: Proposal to solve the `EitherT` problem.

Dan Burton
In reply to this post by Gabriel Gonzalez
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



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


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



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

Re: Proposal to solve the `EitherT` problem.

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



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


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

Gábor Lehel
In reply to this post by Gabriel Gonzalez
+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 <[hidden email]> 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
> <[hidden email]> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Your ship was destroyed in a monadic eruption.

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

John Lato-2
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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Your ship was destroyed in a monadic eruption.

_______________________________________________
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