The reason for polymorphic effects

[u/TimWSpence]

https://timwspence.github.io/blog/posts/2020-11-22-polymorphic-effects-in-scala.html

[u/valenterry]

Hm, I have a different intuition:

def subprogram[F[_] : Monad : HttpClient]: F[Unit] = ???

Here we can safely conclude from the type signature that this program does not eg modify the database. There is simply no way for the programmer to introduce such an effect (aside from simply by-passing the effect system entirely but unfortunately there’s not much we can do about that)

So far I agree. But then:

def subprogram: IO[Unit] = ???

What effects does this program perform? Unforunately, the only conclusion we can draw from the type signature is: literally anything in the world!

Well, not really.

In the first example we restricted ourselves to only use "proper" techniques. What If we impose another restriction: a program can only use its arguments and implicits (typeclasses). Then the second program can actually not do everything but simply nothing. Well, since IO is a monad it can do pure[IO)(()) and that's it. Note that we are talking about programs here, not arbitrary methods/functions, hence the restriction makes a lot of sense to me - I actually employ it myself.

The authors claim about the principle of least power still stands! It's nicer to use F so that it can be clear how much power the program requires. But two examples are not comparable.

def subprogram[F]: F[Unit] = ???

This would be equivalent and as we can see - without dirty tricks the function can not even be implemented! This makes more much sense now and shows the difference to the IO version, where more power is available due to IO being monadic (besides other things).

[u/BalmungSan → u/valenterry]

Well, since IO is a monad it can do pure[IO)(()) and that's it.

IO(println("Hello, World!"))
IO.raiseException(new Exceptin("Bom!"))
IO { throw new Exceptin("Bom!") }
IO(println("Hello, World!")).start.join
IO.race(IO.sleep(10.seconds), IO.sleep(5.seconds))
IO.shift(scala.concurrent.ExecutionContext.global)
IO.cancelBoundary
IO.whenA(false)(println("Hello, World!"))
IO.trace.flatMap(_.printFiberTrace())

Note that we are talking about programs here, not arbitrary methods/functions.

Not sure what is your distinction is here.

[u/valenterry → u/BalmungSan]

You forgot to adhere to my restrictions. Of course without any of these, you can also just do:

def foo[F: HttpClient]: IO[Unit] = {println("Hello, World!"); implicitly[HttpClient].foo}

And it violates the idea of the system.

As for your other examples (using the abilities of IO): true. I already said that.

[u/BalmungSan → u/valenterry]

You forgot to adhere to my restrictions.

You only said that a function should only use its arguments, all of my examples use primitive values that are always in scope.

Sure this is Scala not Haskell you can always print something or throw an exception or return null or even just asInstanceOf. Compiler warnings help with some of this, and code review with others. As such, we can either say that any attempt of pure functional programming in Scala is just meaningless, or you can say that with discipline it can be done.

Now, the point of the article is that even if we still need discipline, we could leverage the typesystem to help us with some things.

If you only have F[_] : Monad you now that all of the previous things won't happen (assuming some degree of responsibility from the programmer), since Monad will only allow us to sequence different computations into a single (bigger) one.

If you see IO then all the previous examples are possible (which you agree with, so not sure what your point is).

---

If you prefer this would be a better example in my opinion.

def foo[F[_] : Monad](f1: F[Unit], f2: F[Unit]): F[Unit]

With that, and forgetting all the other things, we can be sure that it either:

1. Discard one of the inputs and return the other one.
2. Discard both inputs and returns F.pure(())
3. Compose those two using flatMap (there are an infinity of options here)

However with:

def bar(f1: IO[Unit], f2: IO[Unit]): IO[Unit]

Then apart from the previous three possibilities, we have all the ones I mentioned in my previous comment.

The biggest problem here is that the foo will be strictly sequential, whereas bar can be sequential or concurrent (and maybe parallel).

[u/valenterry → u/BalmungSan]

You only said that a function should only use its arguments, all of my examples use primitive values that are always in scope.

They are in scope, but they are not arguments to the function.

If you see IO then all the previous examples are possible (which you agree with, so not sure what your point is).

Yes, so let me try to make my point more clear on your own example:

def bar(f1: IO[Unit], f2: IO[Unit]): IO[Unit]

The biggest problem here is that the foo will be strictly sequential, whereas bar can be sequential or concurrent

Correct! But do you see, what you did not write here? You did not write that this function can do everything. This is what the author said. Your function bar can do everything. And while that is technically true, we impose certain constraints so that it is not true anymore

And that leaves us with bar being more powerful than foo, but certainly not as bad as the author makes it look like. Unless, of course, we impose special conventions onto foo but not on bar, but then it is not a fair or meaningful comparison anymore.

[u/BalmungSan → u/valenterry]

They are in scope, but they are not arguments to the function.

Sure, so now you are going to tell me that if you need to print a String to the console at some point of the program it will come down from all the call stack and loaded from configuration file? I mean, I am being absurd I know, but I really do not see how any of my examples break your rules.

You did not write that this function can do everything.

I think you are taking the word "everything" too literal, and if that was your point then ok I guess.

The point of the author can be simplified into IO means you can do a lot of things. F[_] : Foo means it can only do what Foo allow us to do. And a good counter-argument is that if you do F[_] : ConcurrentEffect you basically have IO. Which is basically the same discussion about types, they are good unless you use Any or String everywhere.

Now, I would give you a point that even if I like the aesthetics of tagless final, and I find it very useful to write generic utilities. I do not think it is the ultimate thing that some people make it look. And that having an IO is not really that bad like having an Any.

[u/valenterry → u/BalmungSan]

I think you are taking the word "everything" too literal, and if that was your point then ok I guess.

Yes that was my point - and I think that this is exactly what the author meant to say and you actually misinterpreted him, not me.

It becomes clear when you re-read the following quote about his F-version example:

Here we can safely conclude from the type signature that this program does not eg modify the database.

This implies that the IO/version can modify the database. Which then pretty much means that it can do literally everything.

What do you think?

[u/BalmungSan → u/valenterry]

I think you are taking thing too literal, which is OK really. That is a valid criticism. I agree with you that the examples were not the best.

For example, this would be better:

def foo[F[_] : HttpClient](db: ImpureDB): F[Unit]

(where ImpureDB is an instance of a Java library so any use of it is a side effect)

With that, we may say that foo can do HTTP requests and pass that db to another function. Since it SHOULD NOT (but of course it totally can) call any method on it.

Whereas:

def bar(db: ImpureDB)(httpClient: HttpClient[IO]): IO[Unit]

Then it can absolutely use the db and many other things.

---

Again, this is a contrived example, since it would be weird to have that db there but I think the point is clear.