Add arrow-related instances

[mniip]

We know that:

• Arrow = Strong + Category,
• ArrowChoice = Choice + Strong + Category
• ArrowLoop = Costrong + Strong + Category

The WrappedArrow class allows using profunctors classes with types that only implement base arrows instances. However since profunctors depends on base, the expectation is that anything that is a Strong Category should also be an Arrow, etc, else you can't use arrow syntax!

Hence I've added the following instances:

• ArrowPlus p => ArrowPlus (WrappedArrow p) -- there was ArrowZero, but not ArrowPlus for some reason
• Star
  • MonadFix f => Costrong (Star f) -- derived from Kleisli
  • Monad f => Arrow (Star f) -- derived from its strength
  • MonadPlus f => ArrowZero (Star f) -- using Alternative (we have a Monad superclass constraint anyway, hence MonadPlus)
  • MonadPlus f => ArrowPlus (Star f) -- using MonadPlus
  • Monad f => ArrowChoice (Star f) -- derived from its choice
  • Monad f => ArrowApply (Star f) -- derived from Kleisli
  • MonadFix f => ArrowLoop (Star f) -- derived from the aforementioned costrength
• Costar
  • Comonad f => Category (Costar f) -- derived from Cokleisli
• CofreeTraversing
  • Category p => Category (CofreeTraversing p) -- things of the form forall x. p (x ⊗ a) (x ⊗ b) (end comonads) naturally form a category
  • (Category p, Profunctor p) => Arrow (CofreeTraversing p) -- derived from its strength
  • (ArrowZero p, Profunctor p) => ArrowZero (CofreeTraversing p) -- natural for "end comonads"
  • (ArrowPlus p, Profunctor p) => ArrowPlus (CofreeTraversing p) -- natural for "end comonads" (the arrows are always in parallel)
  • (Category p, Profunctor p) => ArrowChoice (CofreeTraversing p) -- derived from its choice
• TambaraSum
  • Strong p => Strong (TambaraSum p) -- looks asymmetric, but shouldn't be, given lawful Strong p
  • Costrong p => Costrong (TambaraSum p) -- same benign asymmetry
  • Arrow p => Arrow (TambaraSum p) -- derived from aforementioned strength
  • Arrow p => ArrowChoice (TambaraSum p) -- derived from aforementioned choice
  • ArrowZero p => ArrowZero (TambaraSum p) -- natural for "end comonads"
  • ArrowPlus p => ArrowPlus (TambaraSum p) -- natural for "end comonads"
• PastroSum
  • Strong p => Strong (PastroSum p) -- checks out
• Yoneda -- degenerates when Profunctor p, hence much like its other instances we just extract and proreturn
  • (Arrow p, Profunctor p) => Arrow (Yoneda p) -- derived from its strength
  • (ArrowZero p, Profunctor p) => ArrowZero (Yoneda p)
  • (ArrowPlus p, Profunctor p) => ArrowPlus (Yoneda p)
  • (ArrowChoice p, Profunctor p) => ArrowChoice (Yoneda p) -- derived from its choice
  • (ArrowApply p, Profunctor p) => ArrowApply (Yoneda p)
  • (ArrowLoop p, Profunctor p) => ArrowLoop (Yoneda p) -- derived from its costrength
• Coyoneda -- likewise we just return and proextract
  • (Arrow p, Profunctor p) => Arrow (Coyoneda p) -- derived from its strength
  • (ArrowZero p, Profunctor p) => ArrowZero (Coyoneda p)
  • (ArrowPlus p, Profunctor p) => ArrowPlus (Coyoneda p)
  • (ArrowChoice p, Profunctor p) => ArrowChoice (Coyoneda p) -- derived from its choice
  • (ArrowApply p, Profunctor p) => ArrowApply (Coyoneda p)
  • (ArrowLoop p, Profunctor p) => ArrowLoop (Coyoneda p) -- derived from its costrength
• Rift
  • (Strong p, Costrong q) => Costrong (Rift p q) -- checks out
  • (Choice p, Cochoice q) => Cochoice (Rift p q) -- checks out
• Ran
  • (Strong p, Costrong q) => Costrong (Ran p q) -- same as Rift
  • (Choice p, Cochoice q) => Cochoice (Ran p q) -- same as Rift
• Codensity
  • (Strong p, Costrong p) => Costrong (Codensity p) -- derived from Ran p p
  • (Choice p, Cochoice p) => Cochoice (Codensity p) -- derived from Ran p p
• Day
  • (Profunctor p, Strong q) => Strong (Day p q) -- this one could alternatively be defined using p's strength, but I figured it should target the same argument as does ProfunctorMonad, also swapped is right there.
  • (Choice p, Choice q) => Choice (Day p q)

Things like Category (Pastro p) require Strong p at which point Pastro p <-> p and if you want an arrow you can just extract, so I've decided to not bother with that. Likewise with Category (FreeTraversing p).

[RyanGlScott]

Thanks! Can you mention these changes in the CHANGELOG?

[RyanGlScott]

These Haddocks are now somewhat indirect, as they begin with a list of relationship between base classes and profunctor classes, and then they are followed with an explanation of what the WrappedArrow type actually is. I think it should be the other way around: first say what WrappedArrow is, and then use that to motivate the relationships between the classes.