algebras.scala

  type Algebra[F[_], A]        = F[A] => A
  type AlgebraM[M[_], F[_], A] = F[A] => M[A] // Why isn't F ~> M sufficient?
  type Coalgebra[F[_], A]      = A    => F[A]

  /** What do these type aliases buy - they are composing type
   *  constructors in different orders, but no more simply?
   */
  type GAlgebra[W[_], F[_], A]              = Algebra [   λ[X => F[W[X]]], A]
  type GAlgebraM[W[_], M[_], F[_], A]       = AlgebraM[M, λ[X => F[W[X]]], A]
  type GCoalgebraM[N[_], M[_], F[_], A]     = Coalgebra[λ[X => M[F[N[X]]]], A]
  type GCoalgebra[N[_], F[_], A]            = Coalgebra[λ[X =>   F[N[X]]] , A]
  type CoalgebraM[M[_], F[_], A]            = Coalgebra[λ[X => M[  F[X]] ], A]
  type ElgotCoalgebraM[E[_], M[_], F[_], A] = Coalgebra[λ[X => M[E[F[X]]]], A]
  type ElgotCoalgebra[E[_], F[_], A]        = Coalgebra[λ[X =>   E[F[X]]] , A]

Re: AlgebraM, the A is a specific type – e.g. eval: AlgebraM[Error \/ ?, Expr, Int], so it can’t be abstracted over.

In general, they’re mostly intended for someone to be able to jump to the type definition and understand what those shapes mean, because we found early on that it’s not obvious how to use functions with a type of F[A] => A, so jumping to the docs that mention folds, etc. would help with that.

The specific type aliases I’m less concerned with, but I do find the ones on the left clearer than on the right. Mostly because they pull out the central F and A of the {un}fold.

The aliases on the left are clearer in a narrow context, assuming they are used meaningfully. But when they aren't used consistently, then you multiply the number of names and concepts yet one still must recognize both forms.

If it's case class ElgotCoalgebraM[E[_], M[_], F[_], A](run: Coalgebra[λ[X => M[E[F[X]]]], A]) then it means something when you have an ElgotCoalgebraM in your type signature. But as a type alias it's just one of many permutations of letters.