diff options
| author | Pierre Letouzey | 2017-02-04 01:01:05 +0100 |
|---|---|---|
| committer | Pierre Letouzey | 2017-02-07 22:56:56 +0100 |
| commit | 5484ba750ef4526dde29ffc1474ca5d145f3ec04 (patch) | |
| tree | b3e03ad86078a0b6a4ddcd5204f0977d3e16a5b4 /kernel/type_errors.mli | |
| parent | 93fb83feefbed738aae98b23715465d8b92816da (diff) | |
Extraction: fix complexity issue #5310
A double call to pp_module_type inside Ocaml.pp_specif was
causing an complexity blowup when pretty-printing heavily modular
extracted code.
I wasn't able to figure out why this double call is there. It could
be the leftover of some intermediate work in 2007 before commit 350398eae
(which introduced global printing phases Pre/Impl/Intf).
Anyway I'm reasonably sure that today these two pp_module_type calls produce
the exact same pretty-printed signature (even if there's a large bunch of
imperative states around). Moreover, this duplicated signature is actually
slightly wrong: when we alias a module M with a unambiguous name like Coq__123,
the type of Coq__123 should not be an exact copy of the type of M, but rather
a "strengthened" version of it (with equality between inductive types).
So the best solution is now to use this funny feature of OCaml introduced in 3.12 :
module Coq__123 : module type of struct include M end
This "module type of struct include" is slightly awkward, but short, correct,
and trivial to produce :-). And I doubt anybody will object to the (rare) use
of some 3.12 features in extracted code of 2017...
Diffstat (limited to 'kernel/type_errors.mli')
0 files changed, 0 insertions, 0 deletions
