11
$\begingroup$

Effect systems allowing locally introducing and eliminating effects have started to appear in (more) practical systems recently, but they've always had a reputation as being a major challenge to implement, especially to support functions that are generic passing through effects or support layered effects, and to be very intrusive to the rest of the language implementation.

There are a few obvious high-level approaches (add a hidden parameter for every effect, global variables pointing to handlers, universal specialisation, ...) and I know there have been more sophisticated proposals too, at least theoretically. If I'm building an interpreter or compiler for a language with this sort of effect system in it today, what is the state of the art in practice for going about it? That is, which approach(es) have been found effective in the real implementations that have employed them, beyond toy proofs of concept?

I'm not so much looking at absolute maximum performance here, which I guess is always going to be heavy specialisation in a very optimising compiler, but which high-level approaches to implementation have been found effective and unobstructive. If any have been ruled out and replaced by something better, that's useful information too.

$\endgroup$
14
  • $\begingroup$ For what I know the monad/kaloski arrows the only sensible manner to represent IO in a pure language. With the Haskell's predecessor to monads the dialog system being awful and the generalized exceptions (being exceptions an antipattern in itself, generalized exceptions cannot be a good thing)?, I surely missed some, but I cannot think how could be better than monads, my only idea is to make the language to have the a convenient syntax for monads. $\endgroup$
    – Delfin
    Commented Feb 20 at 20:49
  • 2
    $\begingroup$ @Delfin A few things: (1) I think you mean "Kleisli arrows". (2) A convenient syntax for monads has existed for a long time in the form of Haskell's do notation. (3) There are definitely reasonable alternatives to monads for handling IO in a pure language, going back a number of years. These include uniqueness types (see Mercury and Clean) and algebraic effects (see Eff and Koka). $\endgroup$ Commented Feb 20 at 21:27
  • 3
    $\begingroup$ I'd just note here that this question never mentions IO and is asking about general effect handler systems. You can special-case a single IO effect however you want, but that's not what is being asked here. $\endgroup$
    – Michael Homer
    Commented Feb 20 at 22:15
  • 1
    $\begingroup$ @Delfin As someone who has used Haskell on a regular basis for many years, I strongly disagree with (1). Further, I think the idea that do is an anti-pattern is very unpopular in the Haskell community. It is widely used by me and most others. However, it is of course an opinion someone can hold. There could be a better way to do it as well. But I think do is fine, personally. Regarding (2), I am not an expert on algebraic effects, but I believe they are better seen as a generalization of monads rather than of exceptions. For (4), I would suggest you take another look at algebraic effects $\endgroup$ Commented Feb 20 at 22:17
  • 2
    $\begingroup$ Conventional examples of effects you could use include failure, mutable state, value propagation, exceptions, and, yes, IO. Effect handlers define how to respond to those effects locally, and could vary at different points in the program. A fairly accessible non-IO example is given in this article about writing "abilities" for Unison, which uses the example of a locally-created mutable key-value store and does not include IO anywhere. $\endgroup$
    – Michael Homer
    Commented Feb 20 at 22:38

1 Answer 1

1
$\begingroup$

Leo White is developing an effect system for OCaml 5.0, that might be state-of-the-art in terms of efficiency.

$\endgroup$
1
  • $\begingroup$ To clarify, Leo is working on a new effect typing system but OCaml 5.0 is already released and has effect handlers but where the typing is analogous to unchecked exceptions in Java. $\endgroup$
    – Max New
    Commented Mar 5 at 11:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .