Why does the Alternative typeclass need to be a sub-class of Control.Applicative

Question

Haskell provides a standard typeclass 'Alternative' that effectively provides the <|> operator for any type that is also an Applicative.

As I understand it Alternative is considered a Monoid on Applicative's, however the <|> operator seems to make complete sense in a lot of types that aren't Applicative Functors as well, and there doesn't need to be any specific dependency on the Applicative typeclass for it to work properly.

Is there a reason why Alternative needs to be a subclass of Applicative, and if so is there a standard typeclass to define similar functionality on non-applicative types?

@Lee, that doesn't quite kind-check, as Monoid is a class of types and Alternative is a class of type constructors. I wish we could have locally quantified constraints on type constructors, such as (forall a. Monoid f a) but that's not allowed. — pigworker
Technically Alternative is just "Monoid for Applicatives", so "Monoid" would seem to be the more common case, as I understand it the expected use of the <|> operator is "Pick or ore another", which is somewhat different to mconcat? — James Davies
It seems to me that all the category-theory typeclasses are a bit tangled together, mostly due to historical considerations (i.e., backwards compatibility). I think this is relevant: stackoverflow.com/questions/10167879/…" — MathematicalOrchid

Sjoerd Visscher Sjoerd Visscher · Accepted Answer · 2015-05-27T12:22:51

I think Alt from the semigroupoids package comes closest to being a 'standard' typeclass. https://hackage.haskell.org/package/semigroupoids-5.0.0.1/docs/Data-Functor-Alt.html#t:Alt

Why does the Alternative typeclass need to be a sub-class of Control.Applicative

1 Answers