diff options
| author | Pierre-Marie Pédrot | 2017-12-20 17:44:22 +0100 |
|---|---|---|
| committer | Pierre-Marie Pédrot | 2018-01-11 22:26:11 +0100 |
| commit | 213b32325eb8d98133dc7a7f47f14d2d7af79a53 (patch) | |
| tree | 4edf2a9510039b706773007ca2eca163a0fd5316 /dev | |
| parent | b1ec686f51c061d47535c408435a47e12a69ac5b (diff) | |
Enforce that polymorphic definitions do not generate internal constraints.
In practice, we only send to the kernel polymorphic definitions whose
side-effects have been exported first, and furthermore their bodies have
already been forced. Therefore, no constraints are generated by the kernel.
Nonetheless, it might be desirable in the future to also defer computation
of polymorphic proofs whose constraints have been explicited in the type.
It is not clear when this is going to be implemented. Nonetheless, the
current check is not too drastic as it only prevents monomorphic side-effects
to appear inside polymorphic opaque definitions. The only way I know of to
trigger such a situation is to generate a scheme in a proof, as even abstract
is actually preserving the polymorphism status of the surrounding proof. It
would be possible to work around such rare instances anyways.
As for internal constraints generated by a potentially deferred polymorphic
body, it is easy to check that they are a subset of the exported ones at a
higher level inside the future computation and fail there.
So in practice this patch is not too restrictive and it highlights a rather
strong invariant of the kernel code.
Diffstat (limited to 'dev')
0 files changed, 0 insertions, 0 deletions
