MTL removal plan

[edmundnoble]

So, decision time for #1603. Here is my proposal for 1.0.0:

a) Create a library, Transmogrifier, which will contain monad transformer classes, using another law-testing methodology and type class encoding separate from cats'. a) Remove MonadReader, MonadWriter, MonadState, FunctorFilter, TraverseFilter, MonadFilter and MonadCombine from cats, to be substituted in Transmogrifier. b) Provide operations on Alternative (or Monad; if there's a preference let me know) which can stand in for the MonadCombine operations: unite and separate. c) Keep MonadError in cats, at least for now. Edit: WIth an analogue in Transmogrifier.

[adelbertc]

Will there be a MonadError analogue in this lib? Also can we just call it cats-mtl or something? :P

[edmundnoble]

Yes and yes. Shall I make an issue later to vote on the name once this is accepted?

[kailuowang]

Yes to #MTLexit

[kailuowang]

paging @typelevel/cats

[djspiewak]

I'm assuming that the MTL encoding will be something like the following?

trait WithState[F[_], S] {
  def set(s: S): F[Unit]
  def get: F[S]
  def modify(f: S => S): F[Unit]
}

So no direct compositional encoding (a la scato), and just expecting users to bring in Monad on their own?

[edmundnoble]

Exactly. And a compositional encoding is used for "bundling" type classes on the user end.

[alexandru]

I vote for cats-mtl as the name.

When picking names, please think of non-native English speakers. I don't know what "mogrify" or "trans-mogrification" means and I'd probably get spelling wrong when searching for it :-)

[ceedubs]

I'm 👍 on this assuming that the items in this proposal are an ordered list :). That is, I'd like to see this library take shape and show itself to work before we start removing things from cats.

I'm slightly hesitant to see FunctorFilter drop from cats-core, because I like the idea of providing a type class-based abstraction for filter and collect in the "core" of Cats, but I understand that these are messy/problematic in the current method of encoding type classes, so I'm happy to see how it plays out. Would this really be considered an MTL type class though? It seems like we are drawing the line more at type classes where subtyping becomes problematic and less at which type classes are related to monad transformers (TBH I wonder if MTL is even a bit of a misnomer for the haskell mtl library).

[kailuowang]

@ceedubs how would you define "take shape and show itself to work"? how does that fit into cats' 1.0.0 roadmap?

[djspiewak]

@alexandru Regarding the name, I'm pretty sure it's a reference to Calvin and Hobbes. You're absolutely right that it's a terrible name for non-native English speakers. It's actually pretty hard to remember how to spell it even as a native speaker. :-)

[edmundnoble]

@ceedubs I'm in agreement on that point. I'm working on it at the moment; my hope is that the benefits are obvious from the user's perspective.

Edit: I believe there's a rigorous sense in which you can consider FunctorFilter a MTL class, because it's a RelativeMonad over Option.

@alexandru Agreed, I made the initial repo named cats-mtl.

[ceedubs]

@kailuowang by "take shape and show itself to work" I'd look for the following items:

• The repo exists (easy step one :))
• It has support for the types that we want to remove from Cats
• It has some unit tests showing that it works in some of the currently problematic scenarios
• It has some unit tests showing that it has a usable way to test laws for these MTL classes (@edmundnoble mentioned that these would be done in terms of Free I believe).

As far as how it fits into the Cats 1.0 roadmap, I'm hoping that these items could be accomplished first and that the relevant pieces of Cats could be gone by 1.0. But I'm not the one leading the charge on cats-mtl. Does that sound reasonable, @edmundnoble?

[wedens]

this article can be relevant to testing mtl-like typeclasses in terms of Free

[kailuowang]

sounds like we have a consensus here. Should I move this ticket to "in dev" in (github project)? @edmundnoble ?

[edmundnoble]

Sounds good @kailuowang; got a basic repo (mostly just a clone of cats) up at edmundnoble/cats-mtl.

@wedens @ceedubs I'm leaning against using Free for testing, because that seems to mean a) user code needs to use Free and b) Free needs to leak into the definitions of transformers, meaning my goal of removing (Monad) constraints is dead out of the water. The law-testing indicated in that article appears to be RelativeMonad-based albeit based on an initial encoding; I'm going to try to final-tagless it up to move the constraint to the user.

[edmundnoble]

Just a note: I am not removing the actual MTL transformers themselves from cats because we've got State implemented in terms of StateT, and Writer in terms of WriterT.

[edmundnoble]

After asking in typelevel/cats, I've decided to remove ApplicativeError (with replacement in cats-mtl) as well.

[kailuowang]

@edmundnoble you will move the methods to MonadError right?

[edmundnoble]

:sparkles: in 1.0.0-MF.