matryoshka
matryoshka copied to clipboard
Class-based algebras.
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.
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.
@sellout :+1: (apologies for the delay, I thought I had confirmed this already!).
@sellout So we're approaching the first anniversary of this PR, not sure if that makes it easier or harder to close ;)
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.
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.