# Proposal: merge Data.Functor.Coproduct into transformers

Andreas Abel andreas.abel at ifi.lmu.de
Sun Dec 16 15:36:32 CET 2012

```Standing up against the dictator...

I like neither 'Product' nor 'Sum'.  For one, they are ambiguous already
in type theory.  They mean something different in the context of simple
types and the context of dependent types:

Sum                      Product
simple types     set of tagged elements   set of pairs
dependent types  set of pairs             set of functions

Further they have this number-connotation.  Sum and Product are
mathematician's terms inspired by the cardinality of the sets they
construct (in the simply typed setting), or the likeness to summation
and product terms (in the dependently typed setting).

IMHO, programming is much more based on logics and information theory
than on mathematics and numbers.  The logical content of 'Sum' is making
a decision (left or right) and the one of 'Product' is adjoining two
things, putting them next to each other.  Disjunction and conjunction
would be the logically correct terms, but we can say it simpler.  I
think the current Haskell approach to speak of 'Either' and pairing is
the good one, free of mathematical burden, and it can be extended to
higher-order kinds:

Either  :: * -> * -> *
Either1 :: (* -> *) -> (* -> *) -> (* -> *)
Either2 :: (* -> * -> *) -> (* -> * -> *) -> (* -> * -> *)

(,)   :: * -> * -> *
Pair1 :: (* -> *) -> (* -> *) -> (* -> *)
Pair2 :: (* -> * -> *) -> (* -> * -> *) -> (* -> * -> *)

Cheers,
Andreas

On 16.12.12 1:57 AM, Ross Paterson wrote:
> On Sat, Dec 15, 2012 at 09:24:48PM +0000, Henning Thielemann wrote:
>> Since I proposed that and became aware of the newtype solution in the
>> meantime, I change my mind to:
>>
>>> data Sum f g a = Sum { getSum :: Either (f a) (g a) }
>
> OK, let's do that.  It matches the treatment of Product.
> (So now they'll both clash with Data.Monoid.)
>
> _______________________________________________
> Libraries mailing list
>

--
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/

```