MTL is dead, long live MTL #1751

edmundnoble · 2017-06-30T06:10:09Z

This PR removes the types ApplicativeError, FunctorFilter, MonadCombine, MonadFilter, MonadReader, MonadState, MonadTrans, MonadWriter, TraverseFilter.

It also replaces MonadCombine's operations with equivalents on Alternative (no laws for them anyway), moves methods on ApplicativeError to MonadError; all other functionality will be moved to cats-mtl if it is already not present.

Sorry about the length. There were some missing Alternative instances I had to add as well to make users of MonadCombine less unhappy about the change.

codecov-io · 2017-06-30T07:29:06Z

Codecov Report

Merging #1751 into master will decrease coverage by 0.5%.
The diff coverage is 85.13%.

@@            Coverage Diff             @@
##           master    #1751      +/-   ##
==========================================
- Coverage   95.32%   94.81%   -0.51%     
==========================================
  Files         265      241      -24     
  Lines        4301     4092     -209     
  Branches       96       97       +1     
==========================================
- Hits         4100     3880     -220     
- Misses        201      212      +11

Impacted Files	Coverage Δ
...rc/main/scala/cats/laws/discipline/Arbitrary.scala	`92.18% <ø> (ø)`	⬆️
...ree/src/main/scala/cats/free/FreeApplicative.scala	`100% <ø> (ø)`	⬆️
free/src/main/scala/cats/free/Yoneda.scala	`100% <ø> (ø)`	⬆️
core/src/main/scala/cats/data/package.scala	`85.71% <ø> (ø)`	⬆️
core/src/main/scala/cats/data/EitherK.scala	`100% <ø> (ø)`	⬆️
core/src/main/scala/cats/Functor.scala	`100% <ø> (ø)`	⬆️
core/src/main/scala/cats/data/Ior.scala	`100% <ø> (ø)`	⬆️
core/src/main/scala/cats/Composed.scala	`95.83% <ø> (-0.33%)`	⬇️
core/src/main/scala/cats/data/IdT.scala	`97.14% <ø> (-0.16%)`	⬇️
core/src/main/scala/cats/Traverse.scala	`100% <ø> (ø)`	⬆️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ad17ffc...1e219f2. Read the comment docs.

SystemFw · 2017-06-30T21:48:41Z

Just a thought: in the proposed design, the ApplicativeError methods will no longer be available for Validated. There are specialised variants, but F: MonadError will no longer be able to unify with Validated, which is unfortunate.

johnynek · 2017-06-30T21:56:39Z

I'm -1 on removing ApplicativeError.

What is the motivation for this?

johnynek · 2017-06-30T22:02:55Z

yeah, and we could have a ValidatedT I think, which could give us an ApplicativeError on any Applicative (though I haven't bothered to try to implement to be sure there is not some corner case I'm overlooking.

adelbertc · 2017-06-30T22:14:04Z

Wouldn't ValidatedT be Nested[F, Validated[E, ?], ?] since it would only compose Applicative ?

johnynek · 2017-06-30T22:19:44Z

wait, can't we make an ApplicativeError with a Validated[E, A] and an Applicative[A]?

seems like you can, but I didn't write all the methods. Why do you think you can't? Anything concrete?

johnynek · 2017-06-30T22:29:14Z

okay, I guess you can't:

case class ValidatedT[F[_], E, A](f: F[Validated[E, A]])

class ValidatedTApplicativeError[F[_]: Applicative, E] extends ApplicativeError[ValidatedT[F, E, ?]] {
  def pure[A](a: A): ValidatedT(Applicative[F].pure(Validated.valid(a)))
  def raiseError[A](e: E): ValidateT(Applicative[F].pure(Validated.invalid(e)))
  def handleErrorWith[A](fa: ValidatedT[F, E, A])(f: E => ValidateT[F, E, A]): ValidatedT[F, E, A] =
     // here we can't look inside F[Validate[E, A]] to see if have an error
     // we need a monad on F to do this, it seems.
}

Validated[E, F[A]] can be an applicativeError:

class ValidatedTApplicativeError[F[_]: Applicative, E: Semigroup] extends ApplicativeError[Lambda[T => Validated[E, F[T]]]] {
  def pure[A](a: A): Validated.valid(Applicative[F].pure(a))
  def ap[A, B](f: Validated[E, F[A => B]])(a: Validated[E, F[A]]) =
    f.product(a).map { case (ff, fa) => ff(fa) }
  def raiseError[A](e: E) = Validated.invalid(e)
  def handleErrorWith[A](fa: Validated[E, F[A]])(f: E => Validated[E, F[A]]): Validated[E, F[A]] =
     fa match {
       case v@Validated.Valid(_) => v
       case Validated.Invalid(e) => f(e)
     }
}

so, you can't hide the error inside the F.

It may be more generally that you can compose G[_]: ApplicativeError with F[_]: Applicative to get an Lambda[t => G[F[t]]]: ApplicativeError but I didn't look carefully at that yet. If that is so, then you could add this to Nested,

kailuowang · 2017-07-01T00:31:10Z

It didn't come to my mind that the removal of ApplicativeError will impact Validated usage. I am curious about the motivation too. Is it still a good trade-off?

edmundnoble · 2017-07-01T00:53:30Z

You've hit the nail on the head here, basically. ApplicativeError is too large an abstraction to lift through a transformer stack. Thus, as an abstraction, the only use it has is writing code that works with an EitherT-containing monad transformer stack or just a single Validated on the outside with the call site deciding.

This is why cats-mtl splits it into two classes: ApplicativeHandle and ApplicativeRaise, the latter of which is possible to lift through arbitrary Applicative transformers.

@kailuowang I have already moved the methods to MonadError; the only step remaining to glue over ApplicativeError is to add them to Validated.

My motivation for removing ApplicativeError is that cats-mtl includes Applicative-based transformer type classes, which puts it on equal footing with MonadError when it comes to removal; except MonadError has subtypes, and ApplicativeError doesn't.

It's not a large issue to keep ApplicativeError IMO though; it's just odd that we'd treat errors differently than other MTL classes.

edmundnoble · 2017-07-01T16:38:35Z

To avoid bogging this PR down, I'm taking a vote here: 👍 to keep ApplicativeError, 👎 to take it out.

Edit: This vote will be over on Thursday at noon ET. Ties will be counted as "keep".

Edit 2: Keep it is then.

andyscott · 2017-07-01T17:37:54Z

How quickly will a release of cats-mtl be made against the cats 1.0 milestone release (s)?

kailuowang · 2017-07-02T00:35:33Z

core/src/main/scala/cats/data/WriterT.scala

  implicit def catsDataMonadErrorForWriterT[F[_], L, E](implicit F: MonadError[F, E], L: Monoid[L]): MonadError[WriterT[F, L, ?], E] =
    new WriterTMonadError[F, L, E] {
      implicit val F0: MonadError[F, E] = F
      implicit val L0: Monoid[L] = L
    }
 }

+private[data] sealed abstract class WriterTInstances10 {
+  implicit def catsDataFunctorForWriterT[F[_], L](implicit F: Functor[F]): Functor[WriterT[F, L, ?]] =


Not sure why this is needed. The Coflatmap instance should suffice, no?

kailuowang · 2017-07-02T00:47:46Z

If it's not big deal, I vote for keeping the ApplicativeError which seems less friction and less burden for user migration.

As a related note, I don't have a strong argument for it but I start to feel that the error effect might be worth some special treatment. We did that for MonadError.

edmundnoble · 2017-07-02T04:05:18Z

I don't particularly feel myself like errors deserve any special treatment, however I observe that MonadError does not add any laws to ApplicativeError and it is okay to special-case one MTL class and still avoid ambiguity.

edmundnoble · 2017-07-04T07:02:57Z

@andyscott See https://github.com/edmundnoble/cats-mtl/issues/10.

kailuowang · 2017-07-10T21:30:55Z

free/src/main/scala/cats/free/FreeT.scala

-      override def M = implicitly
-      override def M1 = implicitly
+      def ap[A, B](fa: FreeT[S, M, A])(ff: FreeT[S, M, A => B]): FreeT[S, M, B] = fa.flatMap(a => ff.map(_(a))(M))
+      override final def empty[A]: FreeT[S, M, A] = FreeT.liftT[S, M, A](M1.empty[A])(M)


Not needed if extend with FreeTMonoidK

kailuowang · 2017-07-10T21:31:23Z

free/src/test/scala/cats/free/FreeTTests.scala

-    implicit val freeTSemigroupK: SemigroupK[FreeTOption] = FreeT.catsFreeCombineForFreeT[Option, Option]
-    checkAll("FreeT[Option, Option, Int]", SemigroupKTests[FreeTOption].semigroupK[Int])
+    implicit val freeTSemigroupK: SemigroupK[FreeTOption] = FreeT.catsFreeSemigroupKForFreeT[Option, Option]
+    checkAll("FreeT[Option, Option, Int]", MonoidKTests[FreeTOption].monoidK[Int])


SemigroupKTests here?

edmundnoble · 2017-07-10T23:45:15Z

@kailuowang Comments addressed, thanks.

kailuowang · 2017-07-11T01:05:52Z

thanks @edmundnoble I haven't gone through all of it yet. Will continue tomorrow.

kailuowang · 2017-07-11T21:28:18Z

tests/src/test/scala/cats/tests/ApplicativeTests.scala

@@ -4,7 +4,7 @@ package tests
 import cats.Applicative


-class ApplicativeTests extends CatsSuite {
+class ApplicativeCheck extends CatsSuite {


Not sure why this rename? I noticed that ApplicativeErrorCheck is also using the Check suffix. But that looks like an outlier? The vast majority have the suffix Tests. There is also MonadErrorSuite, BitraverseTest, CategoryTest, ComposeTest, ContravariantTest, FoldableCheck, ReducableCheck, FunctorTest, MonadTest. If you leave this one alone, I can work on another PR to consolidate them.

Will do, good point. I didn't know about MonadErrorSuite or the rest of the Check-style suites.

kailuowang · 2017-07-11T21:39:49Z

tests/src/test/scala/cats/tests/OneAndTests.scala

+      nes.filter(_ % 2 == 0) should ===(nes.unwrap.filter(_ % 2 == 0))
+    }
+  }
+


Just curious, was the arbitrary function in the original test causing problems?

I don't quite know what you mean. The original test in this case is MonadCombineTests, which has been removed, but I did needlessly use _ % 2 == 0 instead of an arbitrary function; that's been corrected now.

Sorry I didn't make it clear. "needlessly use _ % 2 == 0 instead of an arbitrary function" is exactly what I intended to point out.

Ah makes sense :)

kailuowang

👍 thanks so much for this heroic effort.

alexandru · 2017-07-17T04:56:48Z

👍 on this pull request.

I do have a concern about cats-mtl: projects are going to block for it and given that it's a totally new project that hasn't been tested, I wouldn't introduce experimental functionality, only the essentials, as in, only what's being removed here + eventual changes to encoding in order to ensure forward compatibility.

peterneyens

With the removal of all the MTL instances we can clean up some of the "instance hierarchy traits".

I could try to do this clean up in a follow up PR, if you are too busy working on cats-mtl itself ...

And thanks for all this work @edmundnoble !!

peterneyens · 2017-07-18T10:30:22Z

core/src/main/scala/cats/data/EitherT.scala

@@ -535,6 +539,18 @@ private[data] trait EitherTFunctor[F[_], L] extends Functor[EitherT[F, L, ?]] {
  override def map[A, B](fa: EitherT[F, L, A])(f: A => B): EitherT[F, L, B] = fa map f
 }

+private[data] trait EitherTApply[F[_], L] extends EitherTFunctor[F, L] with Apply[EitherT[F, L, ?]] {


This Apply instance (and the Applicative instance below) is inconsistent with the Monad instance for EitherT, see #1467 (and the linked discussions).

I think we need to drop these instances before we merge, all my other comments are things which can be cleaned up.

This is very interesting, and will likely lead to some corrections in cats-mtl as it stands.

peterneyens · 2017-07-18T10:40:18Z

core/src/main/scala/cats/data/Kleisli.scala

  implicit def catsDataFunctorForKleisli[F[_], A](implicit F0: Functor[F]): Functor[Kleisli[F, A, ?]] =
    new KleisliFunctor[F, A] { def F: Functor[F] = F0 }
 }

+private[data] sealed abstract class KleisliInstances6 extends KleisliInstances7 {
+  implicit def catsDataApplicativeErrorForKleisli[F[_], E, A](implicit F0: ApplicativeError[F, E]): ApplicativeError[Kleisli[F, A, ?], E] =


This ApplicativeError instance and the Alternative instance below probably should come before the Applicative, Apply and Functor instances.
The Alternative instance should also come before the MonoidK and SemigroupK instances.

peterneyens · 2017-07-18T10:51:44Z

core/src/main/scala/cats/data/ReaderWriterStateT.scala

-    with RWSTSemigroupK[F, E, S, L] with RWSTMonadTrans[E, S, L] {
+private[data] sealed trait RWSTAlternative[F[_], E, S, L]
+    extends Alternative[ReaderWriterStateT[F, E, S, L, ?]]
+    with RWSTSemigroupK[F, E, S, L] {


We can add with RWSTFunctor[F, E, S, L].

peterneyens · 2017-07-18T10:51:54Z

core/src/main/scala/cats/data/ReaderWriterStateT.scala

-    }
-}
-
-private[data] sealed trait RWSTInstances5 extends RWSTInstances6 {
  implicit def catsDataMonadForRWST[F[_], E, S, L](implicit F0: Monad[F], L0: Monoid[L]): Monad[ReaderWriterStateT[F, E, S, L, ?]] =


We can move this Monad instance to RSTInstances, now that all the other MTL MonadX instances are gone.

peterneyens · 2017-07-18T10:55:11Z

core/src/main/scala/cats/data/StateT.scala

+      }
+    )
+
+  override def map[A, B](fa: StateT[F, S, A])(f: A => B): StateT[F, S, B] = fa.map(f)(F)


If we add override in StateTFunctor we can extend the Alternative and Monad instances, we don't have to override map explicitly.

We can drop this line now that you've added with StateTFunctor.

peterneyens · 2017-07-18T11:02:36Z

core/src/main/scala/cats/data/WriterT.scala

@@ -127,8 +109,8 @@ private[data] sealed abstract class WriterTInstances1 extends WriterTInstances2
 }

 private[data] sealed abstract class WriterTInstances2 extends WriterTInstances3 {
-  implicit def catsDataMonadWriterForWriterT[F[_], L](implicit F: Monad[F], L: Monoid[L]): MonadWriter[WriterT[F, L, ?], L] =
-    new WriterTMonadWriter[F, L] {
+  implicit def catsDataMonadForWriterT[F[_], L](implicit F: Monad[F], L: Monoid[L]): Monad[WriterT[F, L, ?]] =


This can be moved to WriterTInstances0, which means that the Alternative, Applicative, FlatMap, ... instances can be moved up as well.

peterneyens · 2017-07-18T11:06:14Z

free/src/main/scala/cats/free/FreeT.scala

-}
-
-private[free] sealed trait FreeTInstances2 extends FreeTInstances3 {
+sealed trait FreeTInstances extends FreeTInstances0 {


Should we leave this as private[free] ?

peterneyens · 2017-07-18T11:07:39Z

free/src/main/scala/cats/free/FreeT.scala

+private[free] sealed trait FreeTInstances2 extends FreeTInstances3 {
+  implicit def catsFreeAlternativeForFreeT[S[_], M[_]: Alternative: Monad]: Alternative[FreeT[S, M, ?]] =
+    new Alternative[FreeT[S, M, ?]] with FreeTMonad[S, M] with FreeTMonoidK[S, M] {
+      override def M = implicitly[Alternative[M]]


I think we prefer Alternative[M] over implicitly[Alternative[M]].

peterneyens · 2017-07-18T11:11:03Z

free/src/main/scala/cats/free/Yoneda.scala

@@ -35,7 +35,7 @@ object Yoneda {
  /**
   * `Yoneda[F, _]` is a functor for any `F`.
   */
-  implicit def catsFreeFunctorForYoneda[F[_]]: Functor[Yoneda[F, ?]] =
+  implicit def catsCofreeFunctorForYoneda[F[_]]: Functor[Yoneda[F, ?]] =


I think the Free here is the package (like we have catsDataFunctorForKleisli.

peterneyens · 2017-07-18T11:14:33Z

tests/src/test/scala/cats/tests/NestedTests.scala

@@ -18,7 +18,7 @@ class NestedTests extends CatsSuite {

  {
    // Invariant composition
-    implicit val instance = ListWrapper.invariant
+    implicit val instance = Nested.catsDataInvariantForNested(ListWrapper.invariant, ListWrapper.invariant)


Is there a reason that we need to create these instances for Nested (here and below) explicitly?

I'll check again, I had a coverage drop which was fixed by this but I think there was an underlying problem I fixed.

edmundnoble · 2017-07-21T02:49:05Z

All feedback should be addressed.

peterneyens · 2017-07-21T08:04:51Z

tests/src/test/scala/cats/tests/WriterTTests.scala

    implicit val L: Monoid[ListWrapper[Int]] = ListWrapper.monoid[Int]
-    implicit val appErr = WriterT.catsDataApplicativeErrorForWriterT[Validated[String, ?], ListWrapper[Int], String]
+    implicit val appErr = WriterT.catsDataApplicativeForWriterT[Validated[String, ?], ListWrapper[Int]]


Minor, should we call this app instead of appErr ?

peterneyens · 2017-07-21T08:28:24Z

free/src/main/scala/cats/free/FreeT.scala

-    new FreeTCombine[S, M] {
-      override def M = implicitly
-      override def M1 = implicitly
+      def ap[A, B](fa: FreeT[S, M, A])(ff: FreeT[S, M, A => B]): FreeT[S, M, B] = fa.flatMap(a => ff.map(_(a))(M))


I don't think we need this, right?

With override this should give a compiler error because Apply#ap has the parameters in the other order (first ff then fa)

def ap[A, B](ff: F[A => B])(fa: F[A]): F[B]

peterneyens · 2017-07-21T08:32:56Z

core/src/main/scala/cats/data/StateT.scala

+      }
+    )
+
+  override def map[A, B](fa: StateT[F, S, A])(f: A => B): StateT[F, S, B] = fa.map(f)(F)


We can drop this line now that you've added with StateTFunctor.

peterneyens · 2017-07-26T10:06:02Z

free/src/main/scala/cats/free/Coyoneda.scala

@@ -29,6 +29,10 @@ sealed abstract class Coyoneda[F[_], A] extends Serializable { self =>
  /** Converts to `F[A]` given that `F` is a functor */
  final def run(implicit F: Functor[F]): F[A] = F.map(fi)(k)

+  /** Converts to `F[A]` given that `F` is a functor */


"Converts to G[A] given that G is a functor".

edmundnoble · 2017-07-27T02:32:23Z

Merging with two approvals.

alexandru · 2017-07-27T05:55:36Z

🍻💕

kailuowang mentioned this pull request Jun 30, 2017

Prepare for the 1.0.0-MF release #1702

Merged

26 tasks

kailuowang modified the milestones: 1.0.0, 1.0.0-MF Jun 30, 2017

SystemFw mentioned this pull request Jun 30, 2017

Add onError and adaptError to Applicative/MonadError #1739

Merged

kailuowang reviewed Jul 2, 2017

View reviewed changes

julianmichael mentioned this pull request Jul 2, 2017

Add Align typeclass (#1263) #1755

Closed

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch 4 times, most recently from 5154353 to 953f442 Compare July 7, 2017 07:10

edmundnoble changed the title ~~MTL is dead, long live MTL (WIP)~~ MTL is dead, long live MTL Jul 7, 2017

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch 4 times, most recently from 6e88960 to bc4caa9 Compare July 9, 2017 08:16

kailuowang reviewed Jul 10, 2017

View reviewed changes

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch from bc7600f to dc869c3 Compare July 10, 2017 23:15

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch 2 times, most recently from 60ff270 to 8abd354 Compare July 11, 2017 06:49

kailuowang reviewed Jul 11, 2017

View reviewed changes

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch from 8abd354 to 6647523 Compare July 13, 2017 23:38

kailuowang approved these changes Jul 14, 2017

View reviewed changes

LukaJCB approved these changes Jul 16, 2017

View reviewed changes

alexandru approved these changes Jul 17, 2017

View reviewed changes

peterneyens requested changes Jul 18, 2017

View reviewed changes

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch 4 times, most recently from aec604d to 0359f43 Compare July 21, 2017 02:48

peterneyens reviewed Jul 21, 2017

View reviewed changes

MTL begone

61dbe4e

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch from 0359f43 to 61dbe4e Compare July 21, 2017 16:23

peterneyens reviewed Jul 26, 2017

View reviewed changes

peterneyens approved these changes Jul 26, 2017

View reviewed changes

Merge branch 'master' into mtl-is-dead-long-live-mtl

1e219f2

edmundnoble force-pushed the mtl-is-dead-long-live-mtl branch from 43d29b2 to 1e219f2 Compare July 27, 2017 01:26

edmundnoble merged commit 6fefa30 into typelevel:master Jul 27, 2017

MTL is dead, long live MTL #1751

MTL is dead, long live MTL #1751

Conversation

edmundnoble commented Jun 30, 2017

codecov-io commented Jun 30, 2017 • edited Loading

Codecov Report

SystemFw commented Jun 30, 2017

johnynek commented Jun 30, 2017

johnynek commented Jun 30, 2017

adelbertc commented Jun 30, 2017 • edited Loading

johnynek commented Jun 30, 2017

johnynek commented Jun 30, 2017 • edited Loading

kailuowang commented Jul 1, 2017

edmundnoble commented Jul 1, 2017 • edited Loading

edmundnoble commented Jul 1, 2017 • edited Loading

andyscott commented Jul 1, 2017

kailuowang Jul 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kailuowang commented Jul 2, 2017

edmundnoble commented Jul 2, 2017

edmundnoble commented Jul 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmundnoble commented Jul 10, 2017

kailuowang commented Jul 11, 2017

kailuowang Jul 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kailuowang left a comment

Choose a reason for hiding this comment

alexandru commented Jul 17, 2017

peterneyens left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmundnoble commented Jul 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peterneyens Jul 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmundnoble commented Jul 27, 2017

alexandru commented Jul 27, 2017

codecov-io commented Jun 30, 2017 •

edited

Loading

adelbertc commented Jun 30, 2017 •

edited

Loading

johnynek commented Jun 30, 2017 •

edited

Loading

edmundnoble commented Jul 1, 2017 •

edited

Loading

edmundnoble commented Jul 1, 2017 •

edited

Loading

kailuowang Jul 2, 2017 •

edited

Loading

kailuowang Jul 11, 2017 •

edited

Loading

peterneyens left a comment •

edited

Loading

peterneyens Jul 21, 2017 •

edited

Loading