Hacker News Reader

Comment by threeseed | Hacker News Reader

But they also introduce their own color-like problems.

For example with Scala we have ZIO which is an effect system where you wrap all your code in their type e.g. getName(): ZIO[String]. And it doesn't matter if getName returns immediately or in the future which is nice.

But then the problem is that you can't use normal operators e.g. for/while/if-else you need to use their versions e.g. ZIO.if / ZIO.repeat.

So you don't have the colour problem because everything is their colour.

View on HN

But that's only a problem if it's a library and not done on the language level?!

But in the research languages listed they still are colouring function types.

So it doesn't seem to matter whether it's a library or in the language.

Either everything is an effect. Or you have to deal with two worlds of code: effects and non-effects.

Maybe but even if that's the case, you've now got just plain and colored vs before you'd have plain, color A, color B, color C if you go beyond just async as the only other color (e.g. whether you're accepting something by reference or value, whether it's a mutable reference, whether or not the function is compile-time, etc etc etc).

Still seems better to me if you collapse colors >= 1 into a single language system.

Functions can be polymorphic in their effectfulness, so the coloring problem isn't. Functions only become incompatible where you've made them incompatible on purpose - the whole point of annotating functions' effectfulness is to statically know you're not accidentally invoking particular effects where you promised you wouldn't.

Developer of Ante here. Functions in languages with effect systems are usually effect polymorphic. You can see the example in the article of a polymorphic map function which accepts functions performing any effect(s) including no effect(s). For this reason effect systems are one of the solutions to the "what color is your function" problem.

Reply on news.ycombinator.com