| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
y , z".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Minor clean up, no sense in having these as they do nothing.
|
|
|
|
|
|
|
|
TestCompile)
|
|
|
|
4844 and 4824)
|
|
|
|
This fixes bug 5650: evar (x : Prop) should not be slow.
|
|
|
|
flag is set.
|
|
The use of template polymorphism in constants was quite limited, as it
only applied to definitions that were exactly inductive types without any
parameter whatsoever. Furthermore, it seems that following the introduction
of polymorphic definitions, the code path enforced regular polymorphism as
soon as the type of a definition was given, which was in practice almost
always.
Removing this feature had no observable effect neither on the test-suite,
nor on any development that we monitor on Travis. I believe it is safe to
assume it was nowadays useless.
|
|
|
|
|
|
This ought to ease the understanding of the code.
|
|
This was an easy to prove property that I somehow overlooked.
|
|
This is actually useless, the code does not depend on the value of the
entry for side-effects.
|
|
Instead of relying on a mutable state in the object pushed on the libstack,
we export an API in the kernel that exports the side-effects of a given
entry in the global environment.
|
|
We sprinkle a few GADTs in the kernel in order to statically ensure that
entries are pure, so that we get stronger invariants.
|
|
|
|
We use an algebraic type instead of a pair of a boolean and the corresponding
data. For now, this is isomorphic, but this allows later change in the structure.
|
|
|
|
Since camlp5 parses from left, the last ", z" was parsed as part of an
arbitrary long list of "x1 , .. , xn" and a syntax error was raised
since an extra ", z" was still expected.
We support this by translating "x , .. , y , z" into "x , y , .. , z"
and reassembling the arguments appropriately after parsing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This rule is used by opam package coq-coqide
|
|
This ensures that the API is self-contained and is, well, an API.
Before this patch, the contents of `API.mli` bore little relation with
what was used by the plugins [example: `Metasyntax` in tacentries.ml].
Many missing types had to be added.
A sanity check of the `API.mli` file can be done with:
`ocamlfind ocamlc -rectypes -package camlp5 -I lib API/API.mli`
|
|
We sort the dependency graph of API by following a logical declaration
order in `API.{ml,mli}` related to the actual dependency order of Coq
modules.
Things are a bit tricky here as Coq itself relies on the fact that
OCaml treats module interface and implementation separately
dependency-wise; however, when resorting module alias the design seems
to become more coupled.
Currently, API exposes both "namespaces", asserting a large number of
type equality between them, however the `API` namespace is not
self-contained.
In particular, this is a first step to solve problems such as
`Summary.frozen` being used in `API.mli` but not declared by the
`API.Summary` module, etc... In general we follow the invariant that a
type used in `API` must have been declared before.
Keep in mind that OCaml upstream has warned that it maybe tricky to
alias objects in this way. In particular, after API the old `mli` only
files have become full compilation units so we may want to be more
careful here.
The more "correct" declaration order allows us to remove the
`API.Prelude` module, as well as some other declarations that I
consider as spurious.
We still maintain the large number of type aliases which will be
removed in a future patch.
We follow linking order except for files in `intf`, which are
conceptually wrongly placed in the linking hierarchy but this doesn't
matter as the files don't contain any implementation.
We also move a couple of `.mli` only files to `.ml` so we are
consistent, and correct their linking order in `mllib`, even if that
doesn't matter as such `.ml`-only files contain no implementations.
|
|
4844 and 4824)
The commit 8e257d4 (which consider the dummy type Tdummy to be polymorphic and hence
immune of the need for unsafeCoerce) is quite wrong, even if in pratice it worked ok
most of the time. The confusion comes from the fact that the dummy value (__ aka MLdummy
internally) is implemented in Haskell as Prelude.error, hence it has indeed a polymorphic
unrestricted type. But the dummy type Tdummy used when extracting types must be monomorphic
(otherwise type parameters would have to be propagated out of any type definition involving
Tdummy). We implement Tdummy by Haskell's (), which for instance isn't convertible to Any,
as shown by the examples in bug reports 4844 and 4824.
This fix will bring back some more unsafeCoerce in Haskell extraction, including possibly
a few spurious ones. And these extra unsafeCoerce might also hinder further code optimisations.
We tried to mitigate that by directly removing [MLmagic] constructors in front of [MLdummy _].
NB: even if the original bug report mentions universe polymorphism, this issue is
almost unrelated to it. It just happens that when universe polymorphism is off,
an inductive instance is fully placed in Prop (cf. template polymorphism) in the example,
avoiding triggering the issue.
Warning: the test-suite file is there for archiving the repro case, but currently it doesn't
test much (we should run ghc on the extracted code).
|
|
|
