| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14649 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
occurrences to abstract can be given. This allows to force "destruct"
to necessarily abstract over all occurrences of its main argument
(only the sub-arguments that occur in the inductive type of the main
argument have their occurrences constrained by typing). This
incidentally avoids "rewrite" succeeding in rewriting only a part of
the occurrences it has to rewrite. This repairs the failure of
RecursiveDefinition which failed after pattern unification fix from
r14642).
Full support for selecting occurrence of main argument still to be
done though.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14648 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Assume a pile of constants on the left, and a stuck canonical projection
on the right. We are going to unfold the left constants step by step,
and at every step, we are going to recheck that the very same projection
on the right is stuck. The new check for stuck canonical projections is
more expensive, we thus memoize it for the whole sequence of delta steps
on the left.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14646 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
The check looks for 1 canonical projection applied to a meta/evar.
This fails to deal with telescopes that generate unification problems
containing something like "(pi_1 (pi_2 ?))" that is indeed a "stuck"
canonical projection but not of the form recognized by the previous
implementation. The same holds when pi_2 is a general function not
producing a constructor.
This patch checks if the argument of the canonical projection weak head
reduces to a constructor calling whd_betadeltaiota.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14645 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
For instance, consider this inductive type:
Inductive Ind := A | B | C | D.
For detecting "match" on this type, one was forced earlier to write code
in Ltac using "match goal" and/or "context [...]" and long patterns such as:
match _ with A => _ | B => _ | C => _ | D => _ end
After this patch, this pattern can be shortened in many alternative ways:
match _ with A => _ | _ => _ end
match _ with B => _ | _ => _ end
match _ in Ind with _ => _ end
Indeed, if we want to detect a "match" of a given type, we can either
leave at least one branch where a constructor is explicit, or use a "in"
annotation.
Now, we can also detect any "match" regardless of its type:
match _ with _ => _ end
Note : this will even detect "match" over empty inductive types.
Compatibility should be preserved, since "match _ with end" will
continue to correspond only to empty inductive types.
Internally, the constr_pattern PCase has changed quite a lot, a few elements
are now grouped into a case_info_pattern record, while branches are now
lists of given sub-patterns.
NB: writing "match" with missing last branches in a constr pattern was actually
tolerated by Pattern.pattern_of_glob_constr earlier, since the number of
constructor per inductive is unknown there. And this was triggering an uncaught
exception in a array_fold_left_2 in Matching later. Oups. At least this patch
fixes this issue...
Btw: the code in Pattern.pattern_of_glob_constr was quadratic in the number
of branch in a match pattern. I doubt this was really a problem, but having now
linear code instead cannot harm ;-)
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14644 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
stripped leading line returns in front of CDATA.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14643 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
in r14199 (June 2011). Meta's implicitly depend on the context they are
defined in and this has to be taken into account for checking if
occurrences are distinct (in particular, no Var's are allowed as
arguments of a pattern-unifiable Meta). The example expected to be
accepted thanks to r14199 is not a pattern-unification problem (it has
more than one solution) and was anyway already accepted (strange).
Compared to before r14199, aliases expansion and restriction of
pattern unification check to variables occurring in the right-hand
side are however now taken into account.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14642 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
in hypotheses.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14638 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14637 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14636 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14635 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14634 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14633 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14632 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14631 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14630 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Suggestion of Tom Prince, that told me that he has adapted the rippling
tactic to use the "nocore" pseudo-database. Since this tactic was the
only user of these optional arguments ?use_core_db, let's remove them.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14629 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
same name for different statements as noticed by Adam Chlipala on
coq-club, avoiding stating the same axiom twice in distinct files.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14628 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
These annotations are purely optional, but could be quite helpful
when trying to understand the code, and in particular trying to
trace which which data-structure may end in the libobject part
of a vo. By the way, we performed some code simplifications :
- in Library, a part of the REQUIRE objects was unused.
- in Declaremods, we removed some checks that were marked as
useless, this allows to slightly simplify the stored objects.
To investigate someday : in recordops, the RECMETHODS is storing
some evar_maps. This is ok for the moment, but might not be in
the future (cf previous commit on auto hints). This RECMETHODS
was not detected by my earlier tests : not used in the stdlib ?
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14627 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
There are preliminary problems to solve in the semantics of -I/-R which
differs from the one of coqtop:
- in case of ambiguity, internally to -R option, or between two -R/-I options,
it is not clear at all that the semantics is as in coqtop (which by the way
is not canonical either since it seems to depend on the underlying order of
dirs in the file system),
- in the presence of -I dir, Require A.b does not look if dir.A.b exists;
similarly for Declare ML Module "f", Require "f" and Load "f" when f has
a dirname part.
I suggest to have a common library for coqdep, coqdoc and coqtop that
ensures that -I/-R behave consistently for all tools.
Incidentally made coqdep lexer a bit more strict about syntax errors.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14626 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
without knowing it.
Note: location tables have grown a lot, a better representation of the
contents of the glob files in coqdoc might improve efficiency.
Also added keywords.
Information is now obtained from the glob file to know the exact span
of identifiers. Kept a class of identifiers (and enriched them) for
the main purpose of distinguishing between idents and symbols in the
absence of a glob file.
Still a lot of work to do in coqdoc to make it more robust...
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14624 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
packages for utf8.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14623 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14621 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14620 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Kept in "destruct" though.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14619 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14618 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14617 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14616 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
When doing a [check_subtypes env mtb1 mtb2], we used to always add [mtb1]
in the environment. But since the stricter checks of commit r14150, this
is an error if the environment already knows [mtb1] (for instance
when doing (F M) and checking that M is compatible with the type of the
arg of F.
[check_subtypes] now expect [mtb1] to be already in env, and we move the
add_module to the unique call site of this function that requires it.
Moreover, we solve a second issue : when subtyping a functor, we
update the environment once inside the functor, and this is also
refused by the checks of commits r14150. So we first remove the module
name from the env before doing the update. Since the module added
earlier was a functor, there is no inner defs to chase in env.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14615 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Here Foo is Univ.constraints, Univ.universes, Evd.evar_map, Evd.Metamap
Ok, all these structures are currently ocaml's maps or similar,
with a unique empty value, and (=) can be used on them in this
particular case. But using Foo.is_empty is safer : it will work
even if the underlying representation changes. Example : for
spotting non-legitimate use of (=) we might embed a type into
a record with a functional field.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14614 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14613 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14612 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
It appears that registration of hints is the only place (at least
when compiling stdlib) where Univ.universes (the graph of universes)
is stored in vo. More precisely, a Hint Resolve will place in vo
a pri_auto_tactic, which may contain some clausenv, which contain
both a env and a evar_map, each of them containing a Univ.universes
In fact, even env and evar_map are also never stored in vo apart
from hints registration.
Currently, there's nothing wrong in this storing of env / evar_map /
universes. In fact, it seems that every stored universes are actually
empty. Same for env, thanks to awkward lines { cl with env=empty_env }.
But this may hinder potential evolutions of Univ.universes toward a
private per-session representation. Conclusion: it is cleaner
(and not that hard) to store a Term.types instead of the clausenv
in vo, and reconstitute the clausenv at Require-time. On a compilation
of the stdlib, the time effect is hardly noticable (<1%).
NB: a Univ.universes is also stored in initial.coq, but this is a
different story (Write State ...)
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14611 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Consequence of r14597
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14610 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Make the compilation log cleaner.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14609 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14608 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14607 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
tactic notations and ltac definitions (see bug report #2496).
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14606 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14605 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14604 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
#2168)
We replace Global.lookup_constant by our own code that looks for a module
and enters its implementation. This is still preliminary work, I would prefer
to understand more completely the part about module substitutions when
entering an applied functor. But this code already appears to work quite well.
Anyway, since we only search for constants, we don't need to reconstitute a
100% accurate environment, as long as the same objects are in it.
Note:
- Digging inside module structures is slower than just using
Global.lookup_constant. Hence we try to avoid it as long as we could.
Only in front of axioms (or in front of constant unknown to Global)
do we check whether we have an inner-module implementation for this
constant. There is some memoization of the search for internal
structure_body out of a module_path.
- In case of inner-module axioms, we might not be able to print
its type, but only its long name.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14600 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14599 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
a cmx?a
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14598 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
dependencies of name.mllib
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14597 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Adams Chlipala's ltamer now compatible with forthcoming 8.4; thanks to
Matthieu for how to reactivate inh_conv_coerces_to.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14596 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14595 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14594 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14593 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
external type has evars. We now create a new ad hoc evar instead of
having evars as arguments of evars and use filters to resolved them as
was done since about r10124. In particular, this completes the
resolution of bug 2615.
Evar filters for occurrences might be obsolete as a consequence of
this commit.
Also, abstract_tycon, evar_define, second_order_matching which all
implement some form of second_order_matching should eventually be
merged (abstract_tycon looks for subterms up to delta while
second_order_matching currently looks for syntactic equal subterms,
evar_define doesn't consider the possible dependencies in
non-variables-nor-constructors subterms but has a better handling of
aliases, ...).
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14592 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14591 85f007b7-540e-0410-9357-904b9bb8a0f7
|
