Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jan 31 21:17
    codecov-io commented #484
  • Jan 31 21:08
    scala-steward opened #484
  • Jan 31 18:19
    andywhite37 commented #189
  • Jan 31 02:41
    kamilongus starred typelevel/cats-effect
  • Jan 30 00:01
    codecov-io commented #483
  • Jan 29 23:51
    deniszjukow opened #483
  • Jan 29 23:37
  • Jan 29 23:22
  • Jan 29 20:26
    Rui-L starred typelevel/cats-effect
  • Jan 29 18:01
    jdegoes commented #480
  • Jan 29 17:04
    thomaav starred typelevel/cats-effect
  • Jan 28 17:43
    asachdeva starred typelevel/cats-effect
  • Jan 28 07:12
    alexandru commented #480
  • Jan 28 05:45
    codecov-io commented #482
  • Jan 28 05:35
    daron666 opened #482
  • Jan 27 13:56
    codecov-io commented #481
  • Jan 27 13:46
    lrodero opened #481
  • Jan 27 05:47
    codecov-io commented #460
  • Jan 27 05:37
    codecov-io commented #460
  • Jan 27 05:37
    prayagupd synchronize #460
Daniel Spiewak
That will 100% work, but you notice something interesting: the flatMap isn't using its parameter, so you want to use one of the nifty aliases that make things shorter
object Helloer extends IOApp {
  def run(args: List[String]) = IO(println("Hello World")) *> run(args)
This will explode
The problem is that the right hand side (run(args)) is eagerly evaluated
meaning that it needs to be evaluated in order to determine… what run returns
so that's an infinite recursion
before IO even starts running
but you can fix this by using laziness
object Helloer extends IOApp {
  def run(args: List[String]) = IO(println("Hello World")) >> run(args)
This will work
So in theory, there shouldn't be a difference here. Cats really should change *> to be by-name in its right hand side
Excellent. Thanks a lot
Daniel Spiewak
Christopher Davenport
@djspiewak That involves change ap and the entire hierarchy. Quite a big change.
Daniel Spiewak
yeah, I know it's relatively large
this is why I haven't pushed for it for Cats 2 or anything like that
but the distinction between *> and >> is… really really weird
Christopher Davenport
Its just the function closure saving you. Which is operational.
Daniel Spiewak
right but why should I have to think about a difference?
why not make >> eager?
I generally agree with Cats' philosophy of using Eval wherever possible for laziness
but in this particular case, I feel like the split between the two is the worst of both worlds
Christopher Davenport
Opt-out strictness, but this particular case sucks.
Daniel Spiewak
what it comes down to for me
*> is about building control flow
people often want to build flow graphs, not just flow trees
as a function of the language we're in, that necessitates laziness
Christopher Davenport
Alternative[Option].guard(bool) *> Op is still valuable by itself though. So its not fully useless.
Daniel Spiewak
right it's not useless
but it's not as useful as it could be
and it's less-useful in a very insideous way
not all of this shows up in the form of stack overflow errors
the difference between a graph and its spanning tree can be (in the worst case) exponential in space
Christopher Davenport
It will however blow up very swiftly in the case a mistake is made.
Daniel Spiewak
"blow up swiftly"
Christopher Davenport
Daniel Spiewak
you may just notice your laptop getting hotter than it should
that's the really dangerous bit
spanning trees also aren't always exponential
there's a whole host of states in between
so this is kind of what I mean
I feel like anything involving composing control flow which is not inherently normalizing needs to take into account recursion and suffix convergence
which means, as a practical matter, by-name parameters
(and yes, I do realize this is inconsistent with my stance on |+|, which I prefer to be eager)
Christopher Davenport
While it would be nice to lower a constraint, for explanatory reasons. >> is an easy thing to teach in the interrim.
Fabio Labella
in case not everything was covered already, here is a summary for *> vs >>
Moritz Bust
@djspiewak Thank you :)