In both JS and Wasm, performing under `caml_assume_no_perform` must raise `Effect.Unhandled`, expect after installing a handler, i.e. resuming a stack. On the js_of_ocaml side, it is ensured by hav...
This value is the same as in `caml_callback`. I guess it has been chosen because empirically, it avoids trampolining too often but still avoids overflow. I added a comment saying this.
I dont see any equivalent logic on the js side. I seems that caml_assume_no_perform completely forbid effect with wasm while effects could still happen with js after resuming a stack ? I must admit...
Shouldn’t we wait for the new flag to be supported by Dune before documenting it? See https://github.com/ocsigen/js_of_ocaml/pull/1461#issuecomment-2545773411.
```
let doc =
"Select an implementation of effect handlers. [$(docv)] should be one of $(b,cps) \
or $(b,double-translation). Effects won't be supported if unspecified."
```
**Is your feature request related to a problem? Please describe.**
I wish to have support for a more comprehensive comment format to allow runtime type checking with the TypeScript compiler.
...
> @hhugo Is there something remaining for this to be merged? Do you consider [ocaml/dune#11222](https://github.com/ocaml/dune/pull/11222) to be a necessary prerequisite?
[ocaml/dune#11222](htt...