“Adjust” `FunctorT` for directly-recursive types.

[sellout]

FunctorT (and TraverseT) was originally created to support transformations on types that had some way to “map” over the pattern functor, but lacked either a project or embed (i.e., {Co}Free). However, there’s no way to change those type classes to the directly recursive approach and maintain that property. I’m not sure what the right approach is going forward.

1. {Co}Free no longer works with FunctorT, so the original use case is already gone (the old implementations relied on incorrect semantics for those types, so it’s just as well)
2. But maybe there are other types that would benefit from that approach?
3. With some constraint changes, we could fold them into the Recursive and Corecursive type classes.
4. But at that point, there are just generic algebra transformations that would avoid needing additional folds at all.

Ok, so I think I’ve convinced myself that those type classes should go away and we should just implement algebra transformations (e.g., AlgebraicTransform => Algebra) to allow us to continue to write transformations the way we already do.

[paulp]

But maybe there are other types that would benefit from that approach?

I won't pretend I understand all the dimensions of the problem here, but I understand software well enough to say definitively that nothing good has ever come of allowing an italicized maybe to affect one's design.

[sellout]

Yeah, that’s what the conclusion says, too 😉

[paulp]

Right - but maybe my generalized version will find more applications elsewhere. 😃

[sellout]

To be clear (because, upon rereading I think it’s not) my plan is to eliminate the old approach that allows for types that can implement some mapT but lack either a project or embed and to also eliminate the trans* operations, replacing them with a smaller number of algebra transformations (which, actually, already exist in some cases because they were useful with the old approach), so we can still write F[T[G]] => G[T[G]] style transformations, but easily use them in a context that expects an F[T[G]] => T[G] style fold.

[sellout]

With some (not yet PRed) changes that redefine all of the trans* operations in terms of the {co}algebraic operations, these become even more obviously transform <<< project and transform >>> embed. If inference were better, that’d be enough for me. But … we usually have to jump through some hoops to get <<< project to actually work (like, not using point-free, adding some type annotations, etc.), so a few helpers like Transform => Algebra are probably still useful.