diff options
| author |  Pierre Letouzey <pierre.letouzey@inria.fr> | 2015-01-03 18:50:53 +0100 |
|---|---|---|
| committer | Pierre Letouzey <pierre.letouzey@inria.fr> | 2015-01-11 09:56:39 +0100 |
| commit | edf85b925939cb13ca82a10873ced589164391da (patch) | |
| tree | 557735a0f0233f08a49e00169bb2f6afb6f695e2 /kernel/mod_typing.mli | |
| parent | d103a645df233dd40064e968fa8693607defa6a7 (diff) | |
Declarations.mli refactoring: module_type_body = module_body
After this commit, module_type_body is a particular case of module_type.
For a [module_type_body], the implementation field [mod_expr] is
supposed to be always [Abstract]. This is verified by coqchk, even
if this isn't so crucial, since [mod_expr] is never read in the case
of a module type.
Concretely, this amounts to the following rewrite on field names
for module_type_body:
- typ_expr --> mod_type
- typ_expr_alg --> mod_type_alg
- typ_* --> mod_*
and adding two new fields to mtb:
- mod_expr (always containing Abstract)
- mod_retroknowledge (always containing [])
This refactoring should be completely transparent for the user.
Pros: code sharing, for instance subst_modtype = subst_module.
Cons: a runtime invariant (mod_expr = Abstract) which isn't
enforced by typing. I tried a polymorphic typing of mod_expr,
to share field names while not having mtb = mb, but the OCaml
typechecker isn't clever enough with polymorphic mutual fixpoints,
and reject code sharing (e.g. between subst_modtype and subst_module).
In the future (with ocaml>=4), some GADT could maybe help here,
but for now the current solution seems good enough.
Diffstat (limited to 'kernel/mod_typing.mli')
| -rw-r--r-- | kernel/mod_typing.mli | 7 |
1 files changed, 1 insertions, 6 deletions
diff --git a/kernel/mod_typing.mli b/kernel/mod_typing.mli index 21171705d..2e629a3b5 100644 --- a/kernel/mod_typing.mli +++ b/kernel/mod_typing.mli @@ -12,11 +12,7 @@ open Entries open Mod_subst open Names -(** Main functions for translating module entries - - Note : [module_body] and [module_type_body] obtained this way - won't have any [MEstruct] in their algebraic fields. -*) +(** Main functions for translating module entries *) val translate_module : env -> module_path -> inline -> module_entry -> module_body @@ -31,7 +27,6 @@ val translate_modtype : - The second output is the algebraic expression, kept for the extraction. It is never None when translating to a module, but for module type it could not be contain applications or functors. - Moreover algebraic expressions obtained here cannot contain [MEstruct]. *) type 'alg translation = |