Proposal: merge Data.Functor.Coproduct into transformers

[Andreas Abel]

On 11.12.12 1:48 PM, Gábor Lehel wrote:
> On Tue, Dec 11, 2012 at 1:42 PM, wren ng thornton <wren at freegeek.org> wrote:
>> On 12/11/12 7:27 AM, Mario Blazevic wrote:
>>>
>>> On Tue, Dec 11, 2012 at 5:29 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>>>
>>>> I'm not wedded to its current behavior of wrapping an Either. It was kind
>>>> of
>>>> nice that converting to and from Either was a no-op on GHC, but that
>>>> could
>>>> change.
>>>>
>>>> I agree that I wouldn't want to add functions named 'left' and 'right',
>>>> so
>>>> moving to a data type rather than a newtype seems reasonable.
>>>>
>>>> Perhaps
>>>>
>>>> data Coproduct f g a = LeftF (f a) | RightF (g a)
>>>>
>>>> would be a nice color for the bikeshed?
>>
>>
>> +1.
>>
>> I hesitate to suggest another alternative, but if folks are displeased with
>> those names, there's always the tried and true InL/InR or InjL/InjR. But
>> given the precedent of Either, I think LeftF/RightF have a nice ring to
>> them.
>>
>
> Another possibility is
>
> data EitherF f g a = LeftF (f a) | RightF (g a)
>
> But +1 to the proposal no matter the names, +1 to LeftF/RightF, +0 to
> any particular type name (including this one).

That sounds better to me than Coproduct or Sum which smell too much of 
theory.  An alternative would be

   data Either1 f g a = Left1 (f a) | Right1 (g a)

to indicate the arity of the functor.  (The current Either is Either0.) 
One can go on this way and have bifunctors

   data Either2 f g a b = Left2 (f a b) | Right2 (g a b)

and so on...

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/