-
Notifications
You must be signed in to change notification settings - Fork 23
Description
I think the current hierarchy is intended to be
graph LR
Monad -.-> id1([Selective]) --> Applicative --> Functor
Alternative -. ??? .-> id1
Traversable --> Functor
but selectA makes it clear that Selective is at least as general as Applicative. And since <*> is a valid apS, but apS isn’t always <*>, it feels like Selective is more general than Applicative. Also, selectT doesn’t require Applicative f, so it seems like the hierarchy should look more like
graph LR
Monad --> Applicative -.-> id1([Selective]) --> Functor
Alternative --> Applicative
Traversable -.-> id1
Of the existing laws, only associativity is stated without pure, so non-Applicative selective functors would be weaker. But without pure, it’s a semigroup in the category of endofunctors, so that’s what you’d expect.
This is similar to semigroupoid’s Data.Functor.Apply, which I think is also less general than Selective (using the same arguments as above), making the hierarchy
graph LR
Monad --> Applicative -.-> Apply -.-> id1([Selective]) --> Functor
Alternative --> Applicative
Traversable -.-> id1
I think a decent example here is GHC.Arr, which isn’t Applicative (or even Apply), but could have apS via selectT and still seems to satisfy the associative law.
So, does this make sense, or where did I go off the rails?