Existentially quantified types for hoistFix

[alexeytochin]

Thank you for the library!

Why existentially quantified types for
hoistFix :: Functor f => (forall a. f a -> g a) -> Fix f -> Fix g
and
hoistFix' :: Functor g => (forall a. f a -> g a) -> Fix f -> Fix g
type annotations. But not simply
hoistFix :: Functor f => (f (Fix g) -> g (Fix g)) -> Fix f -> Fix g
and
hoistFix' :: Functor g => (f (Fix f) -> g (Fix f)) -> Fix f -> Fix g
Probably the original idea behind was to map f -> g to Fix f -> Fix g.
But in fact the proposed method are more general.

[phadej]

Because hoistMu and hoistNu cannot have types like hoistNu :: Functor f => (f (Fix f) -> g (Fix g)) -> Nu f -> Nu g (well, they could by first converting to Fix and then back, but it's not the point; similarly they actually don't need Functor constraint IIRC).

In other words, if there were an interface for fixed points, its (general) hoist shouldn't talk about Fix.

EDIT: In fact there are type-classes for higher functors, e.g. hkd and barbies, e.g. https://hackage.haskell.org/package/barbies-2.1.1.0/docs/Data-Functor-Barbie.html#t:FunctorB but their FFunctor and BFunctor doesn't provide Functor constraints, so Fix cannot be instance of their classes, but morally it should be.

[alexeytochin]

Did I understand you correctly that functions with signature like
Functor f => (f (Fix g) -> g (Fix g)) -> Fix f -> Fix g
Functor g => (f (Fix f) -> g (Fix f)) -> Fix f -> Fix g
should not be named hoist* in order to avoid confusions but something like buildFixDown and buildFixUp ?