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 Data.Sequencehttp://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-... . 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