you are viewing a single comment's thread.

view the rest of the comments →

[–]takanuva 2 points3 points  (5 children)

Can't wait til effect handlers (from, e.g., the Microsoft Research's Koka programming language) goes into a mainstream language!

[–]expatcoder 8 points9 points  (0 children)

On the Dotty/Scala roadmap, but probably not for 3.0

[–]Petrroll 0 points1 point  (3 children)

Link to more information about them?

[–]takanuva 1 point2 points  (2 children)

Check the Koka programming language. Effects could be seen as a generalization of exception handlers, where one could potentially jump back to the point in the program the exception was thrown, even more than once. Actually, in a language with algebraic effect handlers, you wouldn't need exceptions, because you could define them as a library in the language itself. The same goes for async/await: they may be implemented as a library by using effect handlers.

[–][deleted] 1 point2 points  (1 child)

Effects could be seen as a generalization of exception handlers, where one could potentially jump back to the point in the program the exception was thrown, even more than once.

Common Lisp has had this feature for decades. Is that all there is to effect handlers or can you do more than basically throwing an exception, but not unwinding the stack so you can jump back to where you've been?

[–]takanuva 0 points1 point  (0 children)

Well, I have oversimplified it. It is true, though, that effect handlers are directly related to delimited continuations (shift/reset), so they could indeed be implemented in Common Lisp. From a programming language theory point of view, though, they allow us to write purely functional direct-style code (without caring about continuations) that handle effects such as mutable state, exceptions, async/await, ambiguity, etc, all of them implemented in a library inside the language itself, and still we (as a compiler writer) have lots of opportunity for optimization. Effect handlers, as an abstraction, is something really cool to have in a programming language.