15

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?

duplode
  • 33,731
  • 7
  • 79
  • 150
James Davies
  • 9,602
  • 5
  • 38
  • 42
  • 2
    `Monoid` would be the class for non-applicative types. – Lee May 27 '15 at 11:33
  • 4
    @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 May 27 '15 at 11:38
  • 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 May 27 '15 at 12:01
  • 2
    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: http://stackoverflow.com/questions/10167879/distinction-between-typeclasses-monadplus-alternative-and-monoid" – MathematicalOrchid May 27 '15 at 14:41

1 Answers1

6

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

Sjoerd Visscher
  • 11,840
  • 2
  • 47
  • 59