Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embed the unhandled effect in the exception Unhandled #11185

Closed
favonia opened this issue Apr 12, 2022 · 4 comments · Fixed by #11423
Closed

Embed the unhandled effect in the exception Unhandled #11185

favonia opened this issue Apr 12, 2022 · 4 comments · Fixed by #11423
Milestone

Comments

@favonia
Copy link
Contributor

favonia commented Apr 12, 2022

I wonder if it is possible to embed the unhandled effect in the exception Unhandled. In terms of the OCaml syntax, it's like this:

type exn += Unhandled : 'a Effect.t -> exn

This would enable a library to register a printer via Printexc for its effects, which seems to be useful for debugging (e.g., reminding the user to call some run to handle effects).

@favonia
Copy link
Contributor Author

favonia commented Jun 8, 2022

@kayceesrk It seems that you like this proposal---I wonder how you feel about it? I am asking now because this cannot be easily changed once OCaml 5.0 is released. I intended to make a PR but was then felt uncomfortable hacking the assembly code across all platforms (specifically, the caml_perform in the runtime system). Ideally, I wish this could be implemented along with #11262. One implied change is that Effect.t needs to be predefined, perhaps as eff.

@xavierleroy
Copy link
Contributor

embed the unhandled effect in the exception Unhandled.

@ocaml/caml-devel this must be decided before 5.0 is released, it will be too late afterwards. Please discuss ASAP.

@xavierleroy xavierleroy added this to the 5.0 milestone Jul 7, 2022
@fpottier
Copy link
Contributor

fpottier commented Jul 7, 2022

I don't know what the deep implications of this design decision might be, but from the end user's point of view, it seems desirable to let the exception Unhandled carry the effect that could not be handled.

An alternative might be to not wrap the unhandled effect in an exception at all: just treat unhandled effects in a primitive way, in the same way unhandled exceptions are treated. But that doesn't seem very appealing: it creates a new kind of unexpected situation and (I imagine?) may lead to code duplication in the runtime system and/or in user code.

@kayceesrk
Copy link
Contributor

I have made a PR for this: #11419.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants