-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebranding Cats MTL to emphasize the Capabilities, not the Monad Transformers #516
Comments
Yes. Very yes. Extremely very yes. At least in my mind, capability classes have long been divorced from the monad transformers themselves which gave them their conventional name: MTL. I don't mind keeping the name (if nothing else, it inspired a dope logo), but emphasizing the "implicit capabilities" part of this is absolutely key. More broadly, rewriting the documentation has been a TODO for a long time. I rewrote the library for 1.0 basically to support Coop, which in turn was to support Cats Effect 3's development. As such, I was pretty focused on just hacking out the technical stuff and getting on with the downstream problems as quickly as possible, but that meant I left a lot of stale words behind. At least we no longer have anything referring to the old layered materialization mechanism, but conversely we have nothing which describes All in all: yes. Let's do this. |
All of Ben's points are good, but I am wary of a breaking change for something already so widely depended on. I'd be in favor of a rebrand that makes people forget the origin of the acronym, like KFC or MTV. (I'm struggling for a less American example...) |
@rossabaker To be clear, I was proposing a docs change only, no breaking changes to the APIs. But perhaps you use "breaking change" figuratively, to refer to a major change in the doc content? I wouldn't propose changing the role or semantics of the capability traits, which is what clients should depend on. Pretty much just this:
So concretely, for eg
We can footnote that capability traits of this style originated with a haskell library called MTL, hence the name inheritance, but that the library isn't a "monad transformer library" as such (at the risk of unforgetting the acronym origin 😛 ) |
Yep, I think we're on the same page. New examples and emphases in the docs would be good, and changes that break existing code would not be good. |
I will take a stab at starting this. Timeframe weeks. Getting Started page will need to be heavily reworked/reordered first. I don't think it makes sense to start including examples of eg Ref-backed |
👍 I can't merge my own PRs but I can definitely review/merge contributions!
@benhutchison have you seen typelevel/cats-effect#3385 and typelevel/cats-effect#3429? The idea would be to provide implementations of MTL typeclasses in Cats Effect itself. Primarily we were discussing |
I notice:
Interesting, thanks for the pointer. High time we joined the dots between these 2 key libraries for "Effectful FP". And all the more reason to re-express MTL's concept in updated form. Well, a
|
Unfortunately the current
Sure. Fortunately this is all abstracted by the
Do you mean if you sequence two |
Yes, that one's still at large... Interesting! So at some point, the MTL capability traits ought to be renovated to model weaker, concurrent-friendly forms of State and Ask. This is a classic example of how implementations shape the abstractions that are harvested from them. Monad transformers inherited from Haskell were non-concurrent, and the "missing interfaces" were not visible until people tried to implement them with concurrent backing stores. I'd say something about how a rewrite/rebrand of MTLs docs might be an opportune time to fix the trait hierarchy, but Im worried @rossabaker will roll his eyes knowingly and mutter something about "changes that break existing code would not be good" ;) (In truth, there's no need to bundle the two things, beyond a certain human urge to do so.)
Thinking on this, I don't think Monoid quite captures state update. A Semigroup plus an initial value is needed; almost but not quite the same thing. The difference is that if I later write out the |
We should be able to add a " I can put up a PR with that concept.
Ah, yes indeed! |
I for one would really welcome this reform. However, could we consider doing it consistently across
Edited. While I was originally proposing a |
An issue I raised recently with Cats Effect, around WriterT logging not working well with the concurrent
parEvalMap
in FS2, revealed that the thinking on Cats MTL is shifting.Cats MTL consists of 2 things:
Raise
,Tell
,Handle
andStateful
. These are attached to an abstract effect typeF[_]
to give it an additional capability. For the 4 traits listed, these capabilities are raising errors, emitting logs, handling errors, and read/writing state, respectively.WriterT
for emitting logs withTell
, for example.The documentation currently emphasizes these implementations as the primary role of the library. The homepage leads with the somewhat underwhelming:
Provides transformer typeclasses for cats' Monads, Applicatives and Functors.
You can have multiple cats-mtl transformer typeclasses in scope at once without implicit ambiguity, unlike in pre-1.0.0 cats or Scalaz 7.
However, recent thinking sees more value in the capability traits than the implementations, for at least 2 reasons:
It turns out that MTs prove troublesome in larger, industrial-scale programs that use CE3's
Concurrent
& friends. WriterT[IO.. losing logs in parEvalMap hints at problem with Concurrent instance for WriterT ? cats-effect#3765 is one example of a rash of issues reported in the last couple of years where MTs do surprising things in the presence of concurrency, and consensus is that these surprises are not "fixable". Therefore, we see advice being issued against MT usage, at least in more demanding scenarios.However, many capability traits can be usefully implemented even without MTs, in ways that are better suited to industrial software development, by backing the trait with a mutable
cats.effect.Ref
forTell
&Stateful
, or by "submarine error propagation" in the case ofRaise
andHandle
.Pleasingly, abstraction of the capability is maintained, in that the trait can be implemented either by Ref, or by MT, without touching application code written in terms of the capability. This allows eg unit tests to use a simpler MT-based solution, while larger applications use a Ref approach.
An example implementation of a Ref-backed Tell:
The shifting thinking around MTs affects the role that Cats MTL plays in the Typelevel ecosystem. The capability traits are the gold. We ought to:
Such a rebranding, perhaps accompanied by a blog post at https://typelevel.org/blog/, could see Cats MTL become relevant to a wider range of Typelevel users and lead to a well-deserved increase in library adoption.
The text was updated successfully, but these errors were encountered: