We hit an issue mentioned in The status of eio and effects composition - #19 by rand and How to compose effect handlers with Eio and I’m just curious; do the OCaml maintainers see the fact that the scope of effect handlers is different than the syntactic scope as a problem? Or is it accepted as the de-facto design, we rely on the actual call stack and that’s it?
Actually maybe this is a wrong question; but seems especially relevant in the context of typed effects. This has to be addressed somehow one way or another.
1 Like
I’m not expert on the topic, but I believe the direct implementation of delimited control is always taken as more flexible when you control the back-end (even if you add a form of static safety to their interface). For example, in Scheme, many libraries provide shift/reset - control operators proposed by Danvy and Filinski in their paper Abstracting Control. In their paper, they specify that shift’s context is syntactically delimited by the enclosing reset. However, the vast majority of implementations (that I’m aware of) do it dynamically (e.g. using reset marks that delimited portions of the call stack). It alleviates the need for a static translation (e.g. conversion into CPS or similar) and allows you to link with library code that shifts to handlers the user installs.
I don’t see OCaml changing in this regard (implementation wise), even if features to provide effect safety are eventually provided. It’s a similar situation to exception handlers, really. You can imagine a system similar to Java’s throws clause that propagates information across to users. It’s safe in the context of Java code, but native JNI code can also raise exceptions (as can C code called from OCaml) that propagate to the VM.
Sorry if this reply misses the point, but I’m not sure if you’re proposing a design change to the implementation, the interface of effects (that builds a syntactic restriction above the feature), or the interface of Eio. It’s probably not controversial to say that OCaml’s “effect handlers” are an unsafe, limited, form of delimited control intended for writers of concurrency libraries (which are designed to be efficient, hence the one-shot restriction and - related - fact that captured continuations are not actually first class functions). The linked comment seems to implicitly assume that OCaml’s effect handlers are a feature intended for casual users (doing general programming), which I think is somewhat questionable at this stage.
I think a continuation of your thread about composing effect handlers with Eio would be interesting (and seemingly a specific library/interface concern). I don’t see the OCaml default changing, but I do think it’s interesting to consider how many runtime things play together. I don’t think OCaml has much opinion about which should be the library of choice (as it doesn’t provide a standard for it), so we’re still in a place where much is being worked out (?).
1 Like
I consider effects a feature of OCaml and as such an abstraction that I should be able to use. There’s even effect syntax now! I can’t seriously consider it an implementation detail for concurrency libraries.
If you think about writing programs that involve concurrency like this, effects, in my opinion should remain usable because they are a wonderful abstraction.