-
Notifications
You must be signed in to change notification settings - Fork 702
An algebra of types for the argument of notations #19404
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
An algebra of types for the argument of notations #19404
Conversation
5b0677c to
0b47dab
Compare
0b47dab to
0405cde
Compare
proux01
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arg, this looks huge, I'll try to take a closer look during summer but this may take me some time.
0405cde to
200af3e
Compare
200af3e to
4988a47
Compare
|
Note that if ever useful I can try to isolate the main commit from the auxiliary commits. |
|
Maybe not needed, let me have a look first |
It includes tuple types, lists and the following atoms: terms/patterns, binder, binders.
…e combinators. Also renamed some Idset.t variables into ids.
…ariable or not. Maybe fixing cases where a notation (meta)variable is treated as a (object) name bound in the term.
instead of a pair
8ff4509 to
f1f2cb0
Compare
|
rebased |
|
The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed. |
|
This PR was not rebased after 30 days despite the warning, it is now closed. |
The main objective of the PR is to replace the notation arguments of possible atomic type constr, pattern, and binders by an algebra of types based on the same atoms but composable by means of lists and tuples. It is a step towards granting #7959 as well as a way to make #18531 easier (by easily supporting a new type of notation variables).
The main commit is "A richer type system for notation variables". Two structures are provided:
Constrexpr.notation_arg_type: the type of instances of notation variables as known at parsing time (the atoms are: term, pattern, and binders, that is list of binders, as inforall binders, termor as inmatch term with pattern => term end)Notation_term.notation_var_type: the type of notation variable assigned at interpretation timepatterncarries possible constraints of the forms:`(x,y)in binders and(x,y)inmatchpatterns)constrcarries information on whether it becomes a pattern in notations for patterns (as in(t,u)vsmatch term with (x,y) => term end/fun `(x,y) => term, where there is a change of type), or remain constr (as in(t,u) : typvsfun((x,y) : typ) => termwheretyp` is a constr even when parsed in a pattern expression)Then, a number of correspondences are implemented to adjust an instance as parsed to its expected type as interpreted:
Metasyntax.make_interp_atom_type_recandMetasyntax.make_interp_atom_typeto inform of how parsing and interpretation types differget_term,get_pattern, ... inconstrintern.mlextern_cases_pattern_notation_substitutionandextern_notation_substitutioninconstrextern.mlto build parsing-level instances from interpretation-level instancesis_term_meta,is_pattern_meta, ... innotation_ops.mlto take into account the possible constraints on the type (as well as to manage variables which denote both a term and a pattern, knowing that such notation variables used both as term and either pattern or binders are registered as patterns)Another data type introduced in the PR is:
Notation_term.notation_raw_typewhich reflects the (possibly nested, so as to grant Recursive notation with "pairs" as recursive pattern #7959) recursive and atomic structure of the expressiong being parsedNote: I would not say that the invariants of the code could not be improved further and comments are welcome.
Synchronous overlays: