Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: