Proposal: merge Data.Functor.Coproduct into transformers

Sean Leather leather at
Tue Dec 11 14:03:47 CET 2012

On Tue, Dec 11, 2012 at 1:42 PM, wren ng thornton wrote:

> On 12/11/12 7:27 AM, Mario Blazevic wrote:
>> On Tue, Dec 11, 2012 at 5:29 AM, Edward Kmett 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?
These also work for Sum. ;)

 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.

At first, I couldn't think of a standard library precedent for using L and
R as left and right, but then I remembered ViewL/ViewR in

Of all the above, InL/InR are my favorites, since they pun "in" for
elimination and "inject" for introduction (or you could think "put in").

 Nah, those constructor names are dumb. I prefer Shaun's
>>  data Sum f g a = SumLeft (f a) | SumRight (g a)
> -1. What happened to the vaunted brevity? I type out the names of data
> constructors far more often than the names of type constructors. And those
> data constructor names are obnoxiously long for something as basic as a
> functor coproduct.

The verbosity of the Data.Functor.* modules in transformers is a general
complaint of mine. But it's there already, so I was thinking we should
match the style. Otherwise, I'd be happy with just L/R. ;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list