I've confirmed that the PR passes the testsuite on Arm64.

@kayceesrk Thank you---I learned a few things by checking what you did in amd64/arm64.S. I suppose we are not planning to support other architectures now? (I was very stuck on the assembly code for other architectures, and thus I am curious.)

At the moment, trunk supports native code compilation only on amd64 and arm64.

Thanks. Once this PR has been reviewed, I'll rebase the changes to look sensible.

Pinging the whole of @ocaml/caml-devel again. This is a last-minute change to a stdlib API, something that we have botched in the past. Please review. 3 approvals will be required before this goes in 5.0.

I suppose there's a technical reason for why this was not defined in the Effect module (i.e. Effect.Unhandled).

Also I don't see in the PR where this is defined in the Stdlib. I would expect something to be defined around here. How come is the name actually visible to pattern match on in the tests ?

I suppose there's a technical reason for why this was not defined in the Effect module (i.e. Effect.Unhandled).

Without heavily refactoring the runtime system, caml_perform has to know the index of this constructor (as a numeral in the runtime representation) to construct a correct value of type exn so that the correct exception can be raised. Otherwise, the Effect module would have to somehow pass the constructor index to the primitive caml_perform (because we would not know which index would be assigned to the constructor Unhandled_effect), and I personally don't feel that would lead to better code. For the same reason Continuation_already_taken is built in.

Also I don't see in the PR where this is defined in the Stdlib. I would expect something to be defined around here. How come is the name actually visible to pattern match on in the tests ?

It is as visible as other built-in stuff like int and bool. The type int is also not defined in Stdlib. They are injected into the environment even before the standard library is loaded.

It is as visible as other built-in stuff like int and bool. The type int is also not defined in Stdlib. They are injected into the environment even before the standard library is loaded.

Right but it's likely a good idea to have them properly documented somewhere no ?

@dbuenzli

Right but it's likely a good idea to have them properly documented somewhere no ?

I think it makes sense to redefine the predefined exceptions as stdlib.ml(i) does.

@dbuenzli the exceptions are now documented. See

3 approvals will be required before this goes in 5.0.

@Octachron what else would be needed to get to an approval? I'm feeling a bit guilty to ping @gasche, but he usually has a good taste for API design. Perhaps @sadiqj also as he understands the runtime system bits well.

I'm pretty sure the implementation is fine. What I'm worried about is the design. This is what needs to be eyeballed, preferably by people who 1) use effects already in experimental libraries, or 2) have good taste in library design in general.

The questions that pop in my mind at the moment:

• You say that the type of effects must now be predefined. An alternative would be to move the exception to the Effect module. so that we have type 'a Effect.t and exception Effect.Unhandled : 'a Effect.t -> exn. It requires a different implementation than what you have currently, something similar to what we do for Unix.Error in the Unix library. But my point is that the design should dictate the implementation, not the other way around.
• What are the pros and cons of having a predefined type 'a eff for effects? Why 'a eff and not 'a effect? (I know we have 'a ref and not 'a reference, but we also have 'a array, not 'a arr.)

If possible, I would suggest avoiding the existence of two names for the same type or exception, such as 'a eff versus 'a Effect.t.

@xavierleroy Thanks for the reference to Unix.Error. I wasn't aware of Callback.register_exception, which may simplify the implementation dramatically. Let me have a go at this now.

Let me have a go at this now.

I was hoping we would have the design discussion before implementing...

I was hoping we would have the design discussion before implementing...

Sure. Currently, on trunk, both Unhandled and Continuation_already_taken exceptions are pre-defined so that the assembler stubs may pick up those exceptions from the caml_global_data. This PR proposes to essentially replace exception Unhandled with exception Unhandled : 'a eff -> exn, leaving the exception as pre-defined and additionally having to additionally pre-define the 'a eff type.

With the Callback.register_exception facility, both Unhandled_effect and Continuation_already_taken exceptions may be defined in the Effect module (as they should have been in the first place). The assembler stubs and the interpreter will now call new C functions that raise the corresponding exceptions. This would obviate the need for any pre-defined exceptions. At that point, there is also no need to address #11422 since the exceptions are no longer pre-defined.

I do not see any downsides to implementation. The fast paths, where no exceptions are raised, remain just as fast. The rare slow paths are marginally slower on native code due to the need to switch from OCaml to C stack to call the C functions that raise the corresponding exception.

I am one of the early adopters of OCaml's algebraic effects, though I am not familiar with the OCaml internals. What I can provide is the perspectives of a user. I really like @xavierleroy's questions and here's my current assessment:

Exception Registration (Question 1)

From the end-user point of view, I could not see any differences between all these possible designs other than potential efficiency implications. Moreover, once the promised effect system arrives, none of these would matter because the type checker should prevent unhandled effects. I wanted Unhandled_effect (or Unhandled) because I wanted to to suggest the users of our libraries using some function to handle a particular effect (e.g., You should use ThisLibrary.run to handle effect X). I suppose domainslib is more popular and in fact some main developers are right here, so let me provide an example from that library instead. Its Task module has

val run : pool -> 'a task -> 'a
(** [...omitted by me, favonia...]

    This function should be used at the top level to enclose the calls to other
    functions that may await on promises. This includes {!await},
    {!parallel_for} and its variants. Otherwise, those functions will raise
    [Unhandled] exception. *)

The current type system would not guarantee that this function is "used at the top level to enclose the calls to other functions". I wanted to provide good error messages to direct our users when they fail to follow the instructions. Once we embed the effects, I can use Printexc.register_printer to achieve my goal.

Therefore, from my point of view, how exactly the effect is embedded does not matter, as long as it does not slow down the successful performs. I do not except the users of our library to handle Unhandled_effect at all---I am willing to do extra work so that they would not even see it! When I advocated for the current design (that @kayceesrk implemented here), I was mainly to avoid any runtime overhead in the critical primitive caml_perform. However, as @kayceesrk pointed out, the fast path (for successful performs) is probably still the same and thus the impact is probably minimum.

eff (Question 2)

I don't think it matters to me whether eff/effect is built in or not. As for the names (eff versus effect), I prefer effect over eff for clarity and consistency, and this would probably make my own teaching of OCaml easier. Personally, I can easily internalize it (as exn for extensible/exceptions) but some of my students probably would struggle and complain about these abbreviations. On the other hand, they could just copy the pattern type 'a eff += .... So, I like effect more, and it goes well with Effect.t and Unhandled_effect, but I don't have a strong preference.

What are the pros and cons of having a predefined type 'a eff for effects? Why 'a eff and not 'a effect? (I know we have 'a ref and not 'a reference, but we also have 'a array, not 'a arr.)

If we don't have any predefined exceptions for supporting effect handlers (as I propose to do), then this question does not apply. We will only have an 'a Effect.t type.

Out of my curiosity, I suppose the current registration mechanism requires a concrete value of exn, which means we have to artificially add a constructor Something to eff/effect so that we can register Unhandled_effect Something for once (which sounds strange but okay). Is that accurate? What we need is only the constructor index associated to Unhandled_effect, and it would be great if we can just do that without creating a concrete value of exn. It was not a concern before because we could always use empty strings, zeros, or whatnot to fill in the unused fields, but now we have to do much more. Just to clarify, the registration protocol itself would not matter to a pure OCaml user like me (who has not played with C bindings---yet) but I am curious.

Out of my curiosity, I suppose the current registration mechanism requires a concrete value of exn, which means we have to artificially add a constructor Something to eff/effect so that we can have register Unhandled_effect Something for once (which sounds strange but okay).

Yes. We'd need to declare an effect in the effect.ml module which is only used for constructing a Unhandled_effect value. This effect will not be exposed by the Effect module and hence there is no risk of users observing this effect.

As for the names (eff versus effect), I prefer effect over eff for clarity and consistency, and this would probably make my own teaching of OCaml easier.

In some English-speaking communities "eff" is also used as a euphemised swear word ("eff off!").

I've opened #11423 which uses Callback.register_exception to share the exceptions from the Effect module with the runtime.

Gngngn, sorry these comments where meant to be made on the other PR.

Superceded by #11423. To avoid confusion, let me close this PR.