4 ms·

You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single functio

by Twisol 6y ago

You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function. The benefit is not in `IO` -- its that its absence on a function tells you that it is heavily restricted in what it can do. If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead of `IO`. Even if you end up implementing it using `IO`, you know it can't use more than what your model exposes. Both of these possibilities, while not truly unique (see Agda, etc.), are absolutely rare-to-nonexistent in mainstream languages. Effect modeling is a real shift in perspective.

dmitriid 6y ago
> You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function. Indeed. And that's why I picked up on that particular point in the article that I'm criticising. The article chose to use those examples and those words and they don't show anything beyond what other mainstream languages have. > If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead Yes, you can. No, the article doesn't show that in any way. Just to remind you how I started my comment: --- start quote --- But this article goes out of its way to make the worst possible case for Haskell imaginable. --- end quote --- Does the article show "other models"? No. Does it even try and show how to reason about a function by looking at its type signature alone? Also, no. Would this article be laughed into oblivion had it been about any other language but Haskell? Yes, most likely. > Effect modeling is a real shift in perspective. Ah yes. Does the article talk about this? Does it show a single example of this? No.

by Twisol 6y ago

dmitriid 6y ago

> You don't get any information from `IO _` functions, but that's the case with every mainstream language, where you have an implicit `IO` on every single function. Indeed. And that's why I picked up on that particular point in the article that I'm criticising. The article chose to use those examples and those words and they don't show anything beyond what other mainstream languages have. > If you want to go the other way, you can concretely model the kinds of effects you need parts of your programs to do, and use that model instead Yes, you can. No, the article doesn't show that in any way. Just to remind you how I started my comment: --- start quote --- But this article goes out of its way to make the worst possible case for Haskell imaginable. --- end quote --- Does the article show "other models"? No. Does it even try and show how to reason about a function by looking at its type signature alone? Also, no. Would this article be laughed into oblivion had it been about any other language but Haskell? Yes, most likely. > Effect modeling is a real shift in perspective. Ah yes. Does the article talk about this? Does it show a single example of this? No.