diff options
| author | Pierre Letouzey | 2017-02-04 01:50:58 +0100 |
|---|---|---|
| committer | Pierre Letouzey | 2017-02-07 22:39:58 +0100 |
| commit | 0929a78f9a663ac2bcdf1294de93797b9fdfefad (patch) | |
| tree | 8ea856a927d05b98181f55bb0d20f132c201130e /stm/asyncTaskQueue.ml | |
| parent | aa60931752217a7bf0536acae4e7858f48eb8c8e (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 'stm/asyncTaskQueue.ml')
0 files changed, 0 insertions, 0 deletions
