This is an abuse of this term, which refers to immutable transformations that reuse memory, as in Roc and Koka, not to hiding effects within a function.

> It's the code you would write in Python with types you get from OCaml and no monads.

It's also the code you could write in OCaml itself.

---

Having used OCaml 5 effects, I'm convinced that the trend of globally scoped effect constructors, dynamically scoped handlers and effect-typed functions are the wrong approach. They couple too many orthogonal features.

Handlers should be consumed as (records of) functions that can't leak from their scope (see 'local' in OxCaml, 'ref struct' in C#) and are passed down as a capability. Now you're using two more general mechanisms to express your effects, and other forms of dynamic scoping or dynamic dispatch can be made orthogonal to effects themselves.

Some time back I went on a tour of the fort at Dry Tortugas. Largest brick masonry fort in the world. Many innovations of the form. It was abandoned right as it was completed because barrel rifling had just been invented, dramatically increasing the penetrating power of artillery, rendering brick masonry forts obsolete virtually overnight.

This project evokes a similar feeling.

verse is already used in production but its missing basic features like unions and lambdas, the compiler and runtime are closed source, and its tightly coupled to fortnite but also badly integrated with it at the same time.

koka is way more mature but i couldnt find a single project using it thats more than a demo or personal "lets try a new language" type thing. its explicitly a research language and not going awawy from that any time soon.

I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)

If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)

And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.