Product and Sum Type Parallels in Haskell Type Classes -

it appears type classes such applicative, monad , arrow have sort of sum type equivalent in type classes such alternative, monadplus , arrowplus respectively. example, applicative , alternative can used define following:

(<&&>) :: applicative f => f -> f b -> f (a, b) <&&> b = (,) <$> <*> b  (<||>) :: alternative f => f -> f b -> f (either b) <||> b = (left <$> a) <|> (right <$> b) 

however, in of these cases (as arrowchoice), product type class prerequisite sum type class. there type class rules or common functions depend on prerequisite class? typeclassopedia touches on these relationships, unfortunately couldn't find explicit reason dependency.

arrow class monoidal categories¹ – “monoid” not referring monoid, product-monoid of haskell types. i.e., unit element () , multiplication (,). now, sum types make monoid well, , that's arrowchoice uses. these 2 classes in sense complementary; arrowchoice shouldn't subclass of arrow.

in monoidal category, can go on have monoidal functors. how these come out depends on use type-monoid. (), (,), get

class prodmonoidalftor f   produnit :: () -> f ()   prodzip :: (f a, f b) -> f (a,b)  type (+) = either class summonoidalftor f   sumunit :: void -> f void   sumzip :: f + f b -> f (a+b) 

turns out latter useless, because void initial object of hask, meaning there exists 1 void -> a (namely absurd) all types a. however, make sense comonoidal functors +:

class sumcomonoidalftor f   sumcounit :: f void -> void -- bet find useless too, it's not totally.   sumcozip :: f (a+b) -> f + f b 

that in turn wouldn't make sense product types, because () terminal object.

what's interesting prodmonoidalftor equivalent applicative:

instance (prodmonoidalftor f) => applicative f   pure x = fmap (const x) $ produnit ()   fs <*> xs = fmap (\(f,x) -> f x) $ prodzip (fs,xs) 

one might suspect alternative equivalent summonoidalftor, it's not! actually, equivalent decisive functors, comonads applicatives monads.

whereas alternative , monadplus don't seem have mathematical backing, they're when “un-kleisliing” arrowchoice class, using kleisli category arises prodmonoidalftor. it's bit dubious.

---

¹_{that's considering first/left, second/right, , ***/+++. remaining &&&, ||| , arr, these more specific , imo belong in seperate classes.}