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

Type-checking hooks #6378

Closed
vicuna opened this issue Apr 23, 2014 · 1 comment
Closed

Type-checking hooks #6378

vicuna opened this issue Apr 23, 2014 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Apr 23, 2014

Original bug ID: 6378
Reporter: @alainfrisch
Status: acknowledged (set by @damiendoligez on 2014-06-04T19:54:27Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Monitored by: @gasche @hcarty

Bug description

Several useful meta-programming tasks require to access the type-checking environment (and/or the "expected type"). I propose to add hooks to the type-checker in order to enable such use cases. The hooks would be available in the compiler-libs, so people could tweak the type-checker by creating custom compiler drivers (or create a generic driver which can dynamically load plugins).

Hooks could look like:

val type_expression: (Env.t -> type_expr -> Parsetree.expression -> Parsetree.expression) ref
val type_pattern: (Env.t -> type_expr -> Parsetree.pattern -> Parsetree.pattern) ref
...

Note that hooks return parsetree fragments which are then type-checked normally. The "contract" should be that the hooks only inspect the expected type and environment, but does not do any side effect with them (unification). (A safer approach would be to pass opaque objects to the hooks with a restricted API to inspect them, but this is a lot more work.)

Typical uses of hooks would be to expand extension nodes or to implement features such as autofocusing (#5667).

I think OCamlPro proposed something similar (OCaml Templates).

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

No branches or pull requests

1 participant