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 Data.Sequence.

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. ;)

Regards,

Sean