added whileM, untilM, iterateWhile, etc to Monad #1571

kailuowang · 2017-03-24T15:20:58Z

Continuation on #1216. I didn't add the other methods yet because I want to make sure I get the tests right first. There are no tests present in either original PR or Scalaz .
cc @tpolecat @johnynek

Fixes #1569.

codecov-io · 2017-03-24T16:07:50Z

Codecov Report

Merging #1571 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1571      +/-   ##
==========================================
+ Coverage   92.34%   92.41%   +0.07%     
==========================================
  Files         247      248       +1     
  Lines        3907     3944      +37     
  Branches      132      147      +15     
==========================================
+ Hits         3608     3645      +37     
  Misses        299      299

Impacted Files	Coverage Δ
core/src/main/scala/cats/syntax/monad.scala	`100% <100%> (ø)`
core/src/main/scala/cats/syntax/applicative.scala	`100% <100%> (ø)`	⬆️
core/src/main/scala/cats/Applicative.scala	`72.72% <100%> (+6.06%)`	⬆️
core/src/main/scala/cats/Monad.scala	`96.15% <100%> (+46.15%)`	⬆️

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 18c906b...5d173f1. Read the comment docs.

johnynek · 2017-03-24T19:43:08Z

core/src/main/scala/cats/Monad.scala

+   * returns `true`. The condition is evaluated before the loop body.
+   * Discards results.
+   */
+  def whileM_[A](p: F[Boolean], body: => F[A]): F[Unit] = {


why not use the same style as above(p: F[Boolean])(body: => F[A])?

meant to make them the same, but let it slipped.

johnynek · 2017-03-24T20:35:35Z

core/src/main/scala/cats/Monad.scala

+   * returns `true`. The condition is evalated before the loop body.
+   * Collects the results into an arbitrary `MonadCombine` value, such as a `List`.
+  */
+  def whileM[G[_], A](p: F[Boolean])(body: => F[A])(implicit G: MonadCombine[G]): F[G[A]] = {


can we comment why one of these params is call by name, but not the other. It is not clear to me. Same comment below.

I was under the impression that we don't use by-name params in cats.

@johnynek I think the intention here is to avoid evaluating the body F[A] if p is never true. Thanks to you, I noticed that I missed the memoization of body. I just implemented using a Later.
@edmundnoble internally we don't use by-name params, but we do have plenty of public APIs using it for the sake of ease to use when we don't really want to give user the control over evaluation.
In this particular case, having user passing in a by-name and then memoize it might be misleading. I am open to change to take in a Later[A] instead. Or maybe it's okay to give user the control and just take in an Eval. What do you guys think?

@kailuowang Oh, I didn't know it was solely an optimization to avoid evaluating the body. I don't see any reason to let the user supply an Eval because it will be evaluated more than once; otherwise makes sense to me.

kailuowang · 2017-03-27T00:13:03Z

core/src/main/scala/cats/Monad.scala

+    tailRecM[G[A], G[A]](G.empty)(xs => ifM(p)(
+      ifTrue = {
+        map(b.value) { bv =>
+          Left(G.combineK(xs, G.pure(bv)))


Notice here that to maintain the order of evaluation results I have to append the latest result to the end of the Alternative, which means the performance will be horrible for List.
I see 3 options here:

in the API document, point this out and warn people against data structures with non-constant append performance.

use prepend here and return the G with results in the reverse order, i.e. last result first.

maintain an internal List in the reverse order and construct the G at last in the right order.

@tpolecat and @Atry, what would be your preference here?

I think it's fine to just document the behavior, rather than trying to be clever. This is a general issue with accumulating structures.

johnynek · 2017-03-27T17:53:57Z

core/src/main/scala/cats/Monad.scala

+  def whileM_[A](p: F[Boolean])(body: => F[A]): F[Unit] = {
+    val continue: Either[Unit, Unit] = Left(())
+    val stop: F[Either[Unit, Unit]] = pure(Right(()))
+    val b = Eval.later(body)


why the later vs always semantics? For most monads it shouldn't matter, but for something like Future or Try where there is possibly a side-effect going on, it would.

Do you think these methods would be of practical use for Future or Try? For the conditional param p, neither a Try[Boolean] nor Future[Boolean] will ever change the underneath value, and it's call by value.
It seems to me that the original incentive of introducing these methods are only for data types that track side effects such as IO/Task/StateT. When it comes to other data types like Option or List, they don't make sense to me, at least with current type signatures.

I agree with @kailuowang. This is for data types that have something to say about side-effects or state-passing. Future and Try do not.

That's fine, I was mostly asking because of the Eval.later. If we used Eval.always then you could use Try or Future by sneaking some effect into the call-by-name param, but I'm not a fan of that.

If we want to stick with Eval.later over lazy val, I'd like us to document the reason. The only reason I can see is that it allows the thunk in the call-by-name to be GC'ed after we run, which can be nice. We should comment why because someone will forget and revert since Later is only more work (it uses lazy val + some work).

I agree we should document these not-so-obvious tech decisions somewhere (another example in my mind is typeclass instance priority). Maybe in the contributing?

tpolecat

A few comments but this looks good to me.

tpolecat · 2017-03-29T22:26:31Z

core/src/main/scala/cats/Monad.scala

+    tailRecM[G[A], G[A]](G.empty)(xs => ifM(p)(
+      ifTrue = {
+        map(b.value) { bv =>
+          Left(G.combineK(xs, G.pure(bv)))


I think it's fine to just document the behavior, rather than trying to be clever. This is a general issue with accumulating structures.

tpolecat · 2017-03-29T22:33:11Z

core/src/main/scala/cats/Monad.scala

+  def whileM_[A](p: F[Boolean])(body: => F[A]): F[Unit] = {
+    val continue: Either[Unit, Unit] = Left(())
+    val stop: F[Either[Unit, Unit]] = pure(Right(()))
+    val b = Eval.later(body)


I agree with @kailuowang. This is for data types that have something to say about side-effects or state-passing. Future and Try do not.

tpolecat · 2017-03-30T16:09:47Z

core/src/main/scala/cats/Monad.scala

+  def untilM[G[_], A](f: F[A])(cond: => F[Boolean])(implicit G: Alternative[G]): F[G[A]] = {
+    val p = Eval.later(cond)
+    flatMap(f)(x => map(whileM(map(p.value)(!_))(f))(xs => G.combineK(G.pure(x), xs)))
+  }


So, is val p = Eval.later(cond) what we're doing instead of lazy val p = cond? Is there a discussion somewhere?

Yes. I picked Eval.later(cond) over lazy val because of the optimization in Later, and the fact that an equivalent Need is used in scalaz. But I don't have proof that it is worth the extra allocation.
I am not aware of any discussion regarding choosing between these two in cats.

Ok, I don't feel strongly about it. Was just curious.

Later just uses lazy val under the hood: https://github.com/typelevel/cats/blob/master/core/src/main/scala/cats/Eval.scala#L186

The only reason I can think of to use Later vs lazy val is maybe the thunk can be GC'd in the Later case? cc @non

There's also a locking issue -- lazy vals lock their enclosing class, Later only locks itself.

Yeah see scalaz/scalaz#1144 for discussion (moving my comment up).

okay. Makes sense to me. 👍

johnynek

looks good to me with comments added about Eval.later vs lazy val.

johnynek · 2017-03-30T17:33:13Z

core/src/main/scala/cats/Monad.scala

+  def whileM_[A](p: F[Boolean])(body: => F[A]): F[Unit] = {
+    val continue: Either[Unit, Unit] = Left(())
+    val stop: F[Either[Unit, Unit]] = pure(Right(()))
+    val b = Eval.later(body)


That's fine, I was mostly asking because of the Eval.later. If we used Eval.always then you could use Try or Future by sneaking some effect into the call-by-name param, but I'm not a fan of that.

If we want to stick with Eval.later over lazy val, I'd like us to document the reason. The only reason I can see is that it allows the thunk in the call-by-name to be GC'ed after we run, which can be nice. We should comment why because someone will forget and revert since Later is only more work (it uses lazy val + some work).

kailuowang added the in progress label Mar 24, 2017

johnynek reviewed Mar 24, 2017

View reviewed changes

kailuowang changed the title ~~[WIP] added whileM and whileM_ to Monad~~ [WIP] added whileM, untilM, iterateWhile, etc to Monad Mar 26, 2017

kailuowang force-pushed the add-whileM branch from e948b8a to 685c2b1 Compare March 26, 2017 23:46

kailuowang commented Mar 27, 2017

View reviewed changes

kailuowang changed the title ~~[WIP] added whileM, untilM, iterateWhile, etc to Monad~~ added whileM, untilM, iterateWhile, etc to Monad Mar 27, 2017

kailuowang added 8 commits March 27, 2017 09:17

added whileM and whileM_ to Monad

3d96892

using the same curry style in whileM_

626edd1

memoize the body

a772e49

minor avoid shadowing

6cfeadc

added untilM, iterateWhile / improved the tests

c305b19

changed requirement to Alternative / added syntax

51d62ed

added docs for performance caveat / fix style

5b5eea8

added tests for whenA and unlessA

e44663c

kailuowang force-pushed the add-whileM branch from 069bf9c to e44663c Compare March 27, 2017 13:41

improved tests

5d173f1

johnynek reviewed Mar 27, 2017

View reviewed changes

kailuowang added the Binary Breaking label Mar 30, 2017

tpolecat approved these changes Mar 30, 2017

View reviewed changes

johnynek reviewed Mar 30, 2017

View reviewed changes

johnynek approved these changes Mar 30, 2017

View reviewed changes

kailuowang merged commit 02fb9a1 into typelevel:master Mar 30, 2017

kailuowang deleted the add-whileM branch March 30, 2017 19:22

kailuowang removed the in progress label Mar 30, 2017

kailuowang modified the milestone: 1.0.0-MF Apr 26, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

added whileM, untilM, iterateWhile, etc to Monad #1571

added whileM, untilM, iterateWhile, etc to Monad #1571

kailuowang commented Mar 24, 2017

codecov-io commented Mar 24, 2017 •

edited

Loading

johnynek Mar 24, 2017

kailuowang Mar 24, 2017

johnynek Mar 24, 2017

edmundnoble Mar 25, 2017 •

edited

Loading

kailuowang Mar 25, 2017 •

edited

Loading

edmundnoble Mar 25, 2017

kailuowang Mar 27, 2017 •

edited

Loading

tpolecat Mar 29, 2017

johnynek Mar 27, 2017

kailuowang Mar 27, 2017 •

edited

Loading

tpolecat Mar 29, 2017

johnynek Mar 30, 2017

kailuowang Mar 30, 2017

tpolecat left a comment

tpolecat Mar 29, 2017

tpolecat Mar 29, 2017

tpolecat Mar 30, 2017

kailuowang Mar 30, 2017

tpolecat Mar 30, 2017

johnynek Mar 30, 2017

non Mar 30, 2017

tpolecat Mar 30, 2017

johnynek Mar 30, 2017

johnynek left a comment

johnynek Mar 30, 2017

added whileM, untilM, iterateWhile, etc to Monad #1571

added whileM, untilM, iterateWhile, etc to Monad #1571

Conversation

kailuowang commented Mar 24, 2017

codecov-io commented Mar 24, 2017 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

edmundnoble Mar 25, 2017 • edited Loading

Choose a reason for hiding this comment

kailuowang Mar 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kailuowang Mar 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kailuowang Mar 27, 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

tpolecat left a 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

johnynek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-io commented Mar 24, 2017 •

edited

Loading

edmundnoble Mar 25, 2017 •

edited

Loading

kailuowang Mar 25, 2017 •

edited

Loading

kailuowang Mar 27, 2017 •

edited

Loading

kailuowang Mar 27, 2017 •

edited

Loading