I am against adding the instances for Monad Either to the base package for the same reasons as the ones in the thread "proposal #4095: add Applicative instance for Either". http://www.haskell.org/pipermail/libraries/2010-June/013715.html -Iavor On Wed, Jul 7, 2010 at 6:06 PM, Edward Z. Yang wrote:

Excerpts from Isaac Dupree's message of Fri Jul 02 12:25:33 -0400 2010:

...

It's not quite as simple as that -- as soon as we start making Either an instance of kind (* -> *) classes, such as Functor and Monad, there inevitably becomes some kind of semantic difference between Left and Right.

Right, so what we end up with is short-circuiting computation with different results.

Cheers, Edward _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hello, I don't mind the instance being in MTL because then I can choose if I should use it or not. Adding it to the base library will force it on everyone. I agree that this is a matter of taste but I also think that being careful about what to _omit_ is an important part of good design. So far, I have not seen any convincing reasons about why we might need this instance. -Iavor PS: About (+ e) being used in papers on monads: the instance we are adding is actually "Either e" which would be confusing enough for someone who is just learning about these things. It would be even more confusing when---having finally figured out the correspondence---they tried to define the instance from the paper and got an "overlapping instance" error. PPS: I don't mean to sound too negative here (I am told I have some skill for it though :-). Examples of the utility of this instance would be most welcome though. On Wed, Jul 21, 2010 at 7:54 AM, Ross Paterson wrote:

On Fri, Jul 16, 2010 at 12:58:39AM -0700, Iavor Diatchki wrote:

...

I am against adding the instances for Monad Either to the base package for the same reasons as the ones in the thread "proposal #4095: add Applicative instance for Either". http://www.haskell.org/pipermail/libraries/2010-June/013715.html

namely:

...

The benefit of omitting some instances is that when programmers find them lacking, they might consider an alternative way to achieve their goal. In the case of Monad and Either, my feeling is that an alternative would almost always lead to code which is easier to understand.

I don't believe that witholding valid canonical instances to force a different style is viable in general.  In this particular case there is already an instance in mtl, and (+ e) is used as an example is just about every paper on monads. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Jul 21, 2010 at 11:05:02AM -0700, Iavor Diatchki wrote:

PS: About (+ e) being used in papers on monads: the instance we are adding is actually "Either e" which would be confusing enough for someone who is just learning about these things. It would be even more confusing when---having finally figured out the correspondence---they tried to define the instance from the paper and got an "overlapping instance" error.

Yes, Either is the Prelude version of +. As for the overlap, the same thing will happen if they read in those papers about (->) r and try to declare that -- it's already there.

PPS: I don't mean to sound too negative here (I am told I have some skill for it though :-). Examples of the utility of this instance would be most welcome though.

Those papers have a few.

Hi, Not really, enumerating errors is a good idea in some cases but, as you point out, it is too much work in others. I think that we should simply have another type, isomorphic to Either, but with more suggestive names for the type and its constructors for error handling. Picking appropriate names for things makes a surprisingly big difference when reading large amounts of code, especially when you are not the program's author. In general, I think that a good principle is to aim for designing programs which are "self documenting" in the sense that you could understand an algorithm without having to know/remember implicit conventions such as "errors are usually on the left". Either way :) this is not a huge deal, so if other people find these instances so useful, I should not stop the process. I would be a lot more opposed to "standard" library functions getting Either types for error reporting though. -Iavor On Wed, Jul 21, 2010 at 1:38 PM, Sittampalam, Ganesh wrote:

I find the Either monad is a nice cheap upgrade from the Maybe monad. If I read your objections correctly you would prefer that I define a custom datatype that explicit enumerates the possible errors. That would be rather too heavyweight for casual use, in my opinion.

Iavor Diatchki wrote:

...

Hello, I don't mind the instance being in MTL because then I can choose if I should use it or not. Adding it to the base library will force it on everyone. I agree that this is a matter of taste but I also think that being careful about what to _omit_ is an important part of good design. So far, I have not seen any convincing reasons about why we might need this instance. -Iavor

PS: About (+ e) being used in papers on monads: the instance we are adding is actually "Either e" which would be confusing enough for someone who is just learning about these things.  It would be even more confusing when---having finally figured out the correspondence---they tried to define the instance from the paper and got an "overlapping instance" error.

PPS:  I don't mean to sound too negative here (I am told I have some skill for it though :-).  Examples of the utility of this instance would be most welcome though.

On Wed, Jul 21, 2010 at 7:54 AM, Ross Paterson wrote:

...

On Fri, Jul 16, 2010 at 12:58:39AM -0700, Iavor Diatchki wrote:

...

I am against adding the instances for Monad Either to the base package for the same reasons as the ones in the thread "proposal #4095: add Applicative instance for Either". http://www.haskell.org/pipermail/libraries/2010-June/013715.html

namely:

...

The benefit of omitting some instances is that when programmers find them lacking, they might consider an alternative way to achieve their goal. In the case of Monad and Either, my feeling is that an alternative would almost always lead to code which is easier to understand.

I don't believe that witholding valid canonical instances to force a different style is viable in general.  In this particular case there is already an instance in mtl, and (+ e) is used as an example is just about every paper on monads. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Ross Paterson schrieb:

is already an instance in mtl, and (+ e) is used as an example is just about every paper on monads.

Can you give a reference for "(+ e)"? Is this the (infix) union type constructor (to be written as :+)? If it corresponds to "Either e" should it not be written as "(+) e", because "(+ e)" interpreted like a haskell section would address the second type argument (which is not possible to address in instances)? data a :+ b = Left a | Right b instance Monad ((:+) e) Cheers Christian P.S. "instance Monad (:+ e)" gives a parse error