Class-based algebras.

[sellout]

This adds some functionality, but also generalizes things pretty extremely.

I took the approach suggested by @wemrysi and defined a class for the most generic {co}algebras, then used type alias for the more constrained ones. I ended up having to explicitly define a subclass for GCoalgebra, because scalac doesn’t like Id[Id[_]] showing up in types.

We now

• can .attribute any algebra;
• can .generalize, .generalizeElgot, and .generalizeM any {co}algebra (that doesn’t already have a functor in the generalizing position);
• have transApoM (for @drostron);
• have totally general {co}algebras (GElgot*lgebraM);
• no longer have to define an implicit for each new functor; and
• have some additional docs.

I have a couple issues with this – having to explicitly call an implicit conversion in some cases and still not being able to get .zip from implicit conversions.

Also, there are more changes to be made to make the types consistent. But, in general, algebras implicitly convert to/from functions fine, while coalgebras, maybe not so much.

[codecov-io]

Current coverage is 63.15%

Merging #13 into master will decrease coverage by -2.08% as of 500dfe7

@@            master     #13   diff @@
======================================
  Files           17      14     -3
  Stmts          233     247    +14
  Branches         4       4       
  Methods          0       0       
======================================
+ Hit            152     156     +4
  Partial          0       0       
- Missed          81      91    +10

Review entire Coverage Diff as of 500dfe7

Powered by Codecov. Updated on successful CI builds.

[tpolecat]

There is the potential here for zip to get shadowed by a local definition since it's such a common identifier, so it might make sense to call this method gElgotAlgebraMZip or similar.

On further inspection maybe this was intentional.

[sellout]

Not intentional as such … but I have never managed to have this implicit found, so I always have to explicitly refer to GElgotAlgebraM.zip.zip, with some type parameters thrown in to get it to work. So the short name seemed useful.

I would be happy to give it a long name if it means that implicit search will find it, but no luck so far.

[wemrysi]

You could also add zip as a method on GElgotAlgebraM (and then just delegate to it here) which would eliminate the need to explicitly refer to this instance when you aren't working abstractly with some F[_]: Zip.

[wemrysi]

Could make this and FreeOps final classes.

[wemrysi]

@sellout 👍 (apologies for the delay, I thought I had confirmed this already!).

[wemrysi]

@sellout So we're approaching the first anniversary of this PR, not sure if that makes it easier or harder to close ;)

[sellout]

Hah, yes – I was about to go over this and the even older PR that’s still open. See if there’s anything worth salvaging – at least open some issues.

[paulp]

I would love to see class based algebras, including composable Bialgebras (and Bimonads) as first-class entities.

I think the smart move would be to reduce the function and concept footprint of the current library and create multiple ways to assemble the arguments to a smaller number of functions. A tiny handful of morphisms dominate all uses, and the details of inference and implicits dominate the ergonomics of using the library. If you look at a generalized hylomorphism from different perspectives (input-centric, algebra-centric, monad-centric, adjoint-fold-centric ...) different interfaces emerge. And being explicit about partial application is a tremendous boon for usage because you can lose a lot of the type lambdas and work with single argument type constructors.