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

[Iavor Diatchki]

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
<ganesh.sittampalam at credit-suisse.com> 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 <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
> ===============================================================================
>
>