It would be even more "funny" if you'd wrap that `readFile` inside a thunk that gets captured from the environment by the lambda body. Than you'd have a reference to an effect that is supposed to run only inside the lambda but could be executed by external code. Depending on the effect this can have unexpected up to catastrophic outcomes.
That's why Scala introduces so called "capture checking" to make direct style effect systems safe.
I'm pretty sure the thunk would be tagged by the effects of the inner function, so couldn't be called from an external context not declaring those effects. That's what the effect tracking is for.
> It would be even more "funny" if you'd wrap that `readFile` inside a thunk that gets captured from the environment by the lambda body. Than you'd have a reference to an effect that is supposed to run only inside the lambda but could be executed by external code. Depending on the effect this can have unexpected up to catastrophic outcomes.
Well... yeah? It looks like readFile (a Task) is sufficiently thunk-like to guess that that's the case.
I program in this still regularly. What bad outcomes should I expect?
That's why Scala introduces so called "capture checking" to make direct style effect systems safe.
https://docs.scala-lang.org/scala3/reference/experimental/cc...
To understand the problem better see:
https://www.inner-product.com/posts/direct-style-effects/#ca...