Skip to content

Is Selective in the right place? #83

@sellout

Description

@sellout

I think the current hierarchy is intended to be

graph LR
  Monad -.-> id1([Selective]) --> Applicative --> Functor
  Alternative -. ??? .-> id1
  Traversable --> Functor
Loading

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
Loading

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
Loading

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions