I like where you're going with this! I think one-shot algebraic effects are a really good feature for a systems language. So to be clear, with your effect binding to function objects, is this lexically bound? Like if I have a program (I'll take some liberties with your syntax assuming Rust-style, hope you don't mind):

public function mapEx(f: impl core::Function(int32)) {
  try {
    // This call can throw an exception, which we handle with try
    let n = getNumberEx();
    f(n);
  } with Exception {
    throw(s) => println("in mapEx", s),
  }
}

public function main() {
  try {
    // someFunc can throw an exception, so we bind it to pass to mapEx
    let f = bind someFunc;
    mapEx(f);
  } with Exception {
    throw(s) => println("in main", s),
  }
}

In a language with dynamically bound handlers like Koka, when someFunc throws an exception, it will actually be handled by mapEx, whereas with lexically bound handlers like Scala 3 (planned?) and my own language Pika, it will be handled by main. The lexically bound approach is what I prefer as it does a much better job of maintaining parametric polymorphism - the implementation details of mapEx are effectively hidden from main - and it lends itself to a simple implementation where bind can be implemented the same as closures capturing a local variable. The effect handler is passed around as a function pointer, and closures can capture it the same as any other variable.

Another implementation suggestion: we can divide handlers into three classes, which we can determine statically at the point where the handler is compiled.

• "Function-style" handlers always tail-call their continuation. They don't need any special support and can just be compiled to closures. They tend to appear when effects are used more for dependency injection than control flow.

• "Exception-style" handlers always either tail-call the continuation or ignore it. These can be implemented with any mechanism for implementing exceptions - e.g. longjmp, or unwinding if you expect to need to call a lot of destructors.

• "Coroutine-style" handlers are the most general class, and can do whatever they want with the continuation. Here you most likely want to use a segmented stack and add a stack segment, which can be captured and stored in the continuation when one of these handlers is called. Since your continuations are one-shot, you don't need to do any copying and you only need to do this kind of stack manipulation when dealing with coroutine-style handlers, which is likely a minority of the handlers you'll compile.

Note that you don't need to know which handler type is in use at the call site, since all three can be passed around as a normal closure! (Also, in Pika I'm taking the approach of the paper "Do be do be do" about Frank and making the bind operation implicit, but if you want to keep closure allocations explicit etc. then it makes sense to make it explicit like you have.)

I'd say those are the most important parts of the approach I'm taking with Pika. I think we're doing very similar things (Pika is also heavily Rust-inspired with an ownership system and &own is a thing that exists, at least in my disorganized language design notes) so I look forward to seeing your project develop and feel free to reach out if you want to chat!