Proposal: merge Data.Functor.Coproduct into transformers

[Sean Leather]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121211/d8e4e023/attachment.htm>