#4159: move Monad and MonadFix instances for Either from mtl tobase

Sittampalam, Ganesh ganesh.sittampalam at credit-suisse.com
Wed Jul 21 16:38:23 EDT 2010


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 <ross at soi.city.ac.uk>
> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>> 
> _______________________________________________
> Libraries mailing list
> Libraries at 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 
=============================================================================== 



More information about the Libraries mailing list