Include a class for `hoist`?

[garyb]

There's an MFunctor class in Control.Monad.Morph which is something like what I had in mind:

class MFunctor t where
  hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b

But that imposes a monad constraint. I was thinking more like:

class Functor1 t where
  hoist :: (f ~> g) -> t f ~> t g

With the usual laws:

hoist (f ∘ g) = hoist f ∘ hoist g
hoist id = id

We have quite a few types with hoist operations when you get into free, yoneda, coroutines, etc.

[jdegoes]

hoise is in fact map for a higher-order Functor, where the objects are transformers and the arrows are natural transformations. 😄

[paf31]

Yes, MFunctor should be a functor in the category of monads (takes monads to monads, monad morphisms to monad morphisms, plus appropriate laws). So maybe this should be called FFunctor or FunctorFunctor 😛

[garyb]

Isn't the 1 enough? 😉 That's our usual approach for higher order classes.

[paf31]

I think Functor1 could possibly mean a few different things. Either forall a. Functor (f a), or something from plain type constructors to type constructors, etc. There is also stuff like ProfunctorFunctor etc., so we'll eventually want names where we can differentiate these things.

[garyb]

Ah yeah, that makes sense. What about FunctorF rather than FFunctor then? Since I assume it'd be ProfunctorF in that scheme also?

FunctorFunctor just seems too silly, even though it's entirely accurate 😆

[paf31]

It's sort of a shame that we can't write these classes once. I think we'd need at least polykinds and constraint kinds to do that.

I'm fine with any name that addresses the concern above.

[garyb]

I know! I've made attempts and doing them the right way in Haskell without much luck either, so either I was taking the wrong approach, or you need some really fancy type magic to make it work.

[paf31]

I wrote some thoughts along these lines a while ago here actually.

[paf31]

I think purescript-mmorph and purescript-hoist are the way to go here. Close?

[garyb]

👍