MonadErrorcannot be refactored as an algebra, because it has
F[_]in contravariant position (and the algebra could not have an
FunctorKas cats calls it)
Extensibility for the masses)
Seq. I'm looking into mostly using directly
Listbut I'm scared that it could make matters worse as it doesn't fuse and some of the collections hidden behind some of the
Seqmight do it.
the ideas behind final tagless are two:
This is a genius idea, not trivial at all, and the technique definitely deserves a name, especially when you take it in its entirety (e.g. do parsing or optimisations on final tagless languages)
monad-control, and so on
lenspulls in the whole world
I consider "mtl style" to be more general.
yeah, so I think we agree that "this thing" needs a name cause there are different things to talk about ;)
FFunctorfor an algebra, but it'd be nice to have something like
DerivingViais a nice way for the "use typeclasses" crowd to continue using their encoding, but I find it to be like reasoning about
implicitsearch and I really just prefer explicit passing of things.
@mdedetrich actually Haskeller were dealing with a problem that required final tagless, but it was a specific one, and then we found out about the broader benefits of the approach. Btw this problem is why Martin is (incorrectly, imho) still skeptical about final tagless: lifting monad transformers automatically. It's akin to thinking that the Web is useless because you have no need to create documents with links to share scientific articles at CERN: basically a fallacy that the reason something was created it's also the reason it still exists/is useful.
The same fallacy happens with
IO and laziness.
ReaderTand a type level set to hold the algebras, but I found the mental overhead to be much higher than the boilerplate problem it was solving. I've learn to just accept a little bit of boilerplate in exchange for the explicit nature of the code.