aboutsummaryrefslogtreecommitdiffhomepage
path: root/pretyping/evd.ml
Commit message (Collapse)AuthorAge
* Fixing evarmap implementation.Gravatar Pierre-Marie Pédrot2015-10-14
|
* Univs: fix bug #3807Gravatar Matthieu Sozeau2015-10-08
| | | | Add a flag to disallow minimization to set
* Univs: fix FingerTree contrib.Gravatar Matthieu Sozeau2015-10-07
| | | | | Let merge_context_set be lenient when merging the context of side effects of an entry from solve_by_tac.
* Univs: add Strict Universe Declaration option (on by default)Gravatar Matthieu Sozeau2015-10-07
| | | | | | | | | This option disallows "declare at first use" semantics for universe variables (in @{}), forcing the declaration of _all_ universes appearing in a definition when introducing it with syntax Definition/Inductive foo@{i j k} .. The bound universes at the end of a definition/inductive must be exactly those ones, no extras allowed currently. Test-suite files using the old semantics just disable the option.
* Fix bug #4354: interpret hints in the right env and sigma.Gravatar Matthieu Sozeau2015-10-06
|
* Univs: fix after rebase (from_ctx/from_env)Gravatar Matthieu Sozeau2015-10-02
|
* Univs (evd): deal with global universes and sideffGravatar Matthieu Sozeau2015-10-02
| | | | | | - Fix union of universe contexts to keep declarations - Fix side-effect handling to register new global universes in the graph.
* Forcing i > Set for global universes (incomplete)Gravatar Matthieu Sozeau2015-10-02
|
* Univs: force all universes to be >= Set.Gravatar Matthieu Sozeau2015-10-02
|
* Universes: enforce Set <= i for all Type occurrences.Gravatar Matthieu Sozeau2015-10-02
|
* Fixing loss of extra data in Evd.Gravatar Pierre-Marie Pédrot2015-09-27
|
* Univs: Add universe binding lists to definitionsGravatar Matthieu Sozeau2015-09-14
| | | | | ... lemmas and inductives to control which universes are bound and where in universe polymorphic definitions. Names stay outside the kernel.
* Fix bug #4254 with the help of J.H. JourdanGravatar Matthieu Sozeau2015-06-26
| | | | | | | | | | | | | | | 1) We now _assign_ the smallest possible arities to mutual inductive types and eventually add leq constraints on the user given arities. Remove useless limitation on instantiating algebraic universe variables with their least upper bound if they have upper constraints as well. 2) Do not remove non-recursive variables when computing minimal levels of inductives. 3) Avoid modifying user-given arities if not necessary to compute the minimal level of an inductive. 4) We correctly solve the recursive equations taking into account the user-declared level.
* Fixup for 866c41bGravatar Enrico Tassi2015-05-28
|
* Fix bug #4159Gravatar Matthieu Sozeau2015-05-27
| | | | | | Some asynchronous constraints between initial universes and the ones at the end of a proof were forgotten. Also add a message to print universes indicating if all the constraints are processed already or not.
* Adding an extensible global state to evarmaps.Gravatar Pierre-Marie Pédrot2015-05-19
| | | | | | | Evars already had their own extensible state, but adding it globally allows to write out extensible state-passing code in e.g. plugins. The additional data is hopefully transparently preserved by the code out there. Trespassers ought to be prosecuted.
* Tactical `progress` compares term up to potentially equalisable universes.Gravatar Arnaud Spiwack2015-04-22
| | | | | Followup of: f7b29094fe7cc13ea475447bd30d9a8b942f0fef . In particular, re-closes #3593. As a side effect, fixes an undiscovered bug of the `eq_constr` tactic which didn't consider terms up to evar instantiation.
* Add function to fix the non-substituted universe variables of an evar_map.Gravatar Matthieu Sozeau2015-03-17
|
* [Proofview.tclPROGRESS]: do not consider that trivial goal instantiation is ↵Gravatar Arnaud Spiwack2015-02-24
| | | | | | | | | | progress. Also compare goals up to evar instantiation (otherwise no progress would be observed when only unification occurs, unless some [nf_evar] is done). Performance look unchanged so far. Some code from [Evd] which was used only in [tclPROGRESS] have been moved out (and [progress_evar_map] was now dead, so I killed it). Fixes bugs (one reported directly on coqdev, and #3412).
* Compensating 6fd763431 on postponing subtyping evar-evar problems.Gravatar Hugo Herbelin2015-02-23
| | | | | | | Pushing pending problems had the side-effect of later solving them in the opposite order as they arrived, resulting on different complexity (see e.g. #4076). We now take care of pushing them in reverse order so that they are treated in the same order.
* Continuing experimentation on what part of the instance of an evarGravatar Hugo Herbelin2015-02-21
| | | | | | | | | | | | | to display by default (see bc8a5357889 - 17 Oct 2014): - not printing instances for let-in anymore even when expanded (since they are canonical up to conversion) - still printing x:=x in [x:=x;x':=x] when x is directly an instance of another var, but not in [x:=x;x':=S x] This can be discussed, but if ever this is to be changed, it should not be printed in [x:=x;x:=?n] with ?n implicitly depending on x (otherwise said, variables which are not displayed in instances of internal evars should not contribute to the decision of writing x:=x in the instance).
* Univs: proper printing of global and local universe names (onlyGravatar Matthieu Sozeau2015-01-17
| | | | printing functions touched in the kernel).
* Update headers.Gravatar Maxime Dénès2015-01-12
|
* Fix merging of name maps in union of universe contexts.Gravatar Matthieu Sozeau2014-12-14
|
* Tentatively more informative report of failure when inferringGravatar Hugo Herbelin2014-12-11
| | | | pattern-matching predicate.
* Improved tracking of the origin of evars.Gravatar Hugo Herbelin2014-12-07
|
* More consistent printing of evars in evar_map debugging printer.Gravatar Hugo Herbelin2014-12-05
|
* New approach to deal with evar-evar unification problems in differentGravatar Hugo Herbelin2014-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | types: we downcast the evar in the higher type to the lower type. Then, we have the freedom to choose the order of instantiation according to the instances of the evars (e.g. choosing the instantiation for which pattern-unification is possible, if ever it is possible in only one way - as shown by an example in contribution Paco). This still does not preserve compatibility because it happens that type classes resolution is crucially dependent on the order of presentation of the ?n=?p problems. Consider e.g. an example taken from Containers. Both now and before e2fa65fccb9, one has this asymmetry: Context `{Helt : OrderedType elt}. Check forall x y r l h, @Equivalence.equiv _ _ _ x y -> In x (Node l x r h). --> @Equivalence.equiv QArith_base.Q QArith_base.Qeq QArith_base.Q_Setoid x y Context `{Helt : OrderedType elt}. Check forall x y r l h, In x (Node l x r h) -> @Equivalence.equiv _ _ _ x y. --> @Equivalence.equiv elt (@_eq elt Helt) (@OT_Equivalence elt Helt) Then, embedding this example within a bigger one which relies on the ?n=?n' resolution order, one can get two incompatible resolution of the same problem. To be continued...
* Option -type-in-type continued (deactivate test for inferred sort ofGravatar Hugo Herbelin2014-11-19
| | | | | inductive types + deactivate test for equality of sort + deactivate the check that the constraints Prop/Set <= Type are declared).
* new: Optimize Proof, Optimize HeapGravatar Enrico Tassi2014-11-09
| | | | | | | | - drops all Defined entries from the evar map (applying the subst to the initial evar and the undefined evars types). - call Gc.compact Now the question is: where should these two commands be documented?
* Fixing a bug in change of subst_defined_metas in bcba6d1bc9f769da:Gravatar Hugo Herbelin2014-11-08
| | | | | | | | | One missing evar was making the whole substitution fail. The bug actually existed a priori also in the case where only metas are substituted (i.e. before bcba6d1bc9f769da), leading to limit the number of situations where it could be effectful. This fixes current failures of RelationAlgebra and CFGV.
* Experimentally applying eager evar substitution at the same time asGravatar Hugo Herbelin2014-11-04
| | | | | | | | | eager meta substition in w_unify, so as to preserve compatibility after PMP's move of (setoid) rewrite clauses from metas to evars (fbbe491cfa). Hoping it is compatible for non-rewrite uses of the eager meta flag, and that it is not too costly.
* Removing dead code from Evd.Gravatar Pierre-Marie Pédrot2014-10-27
|
* Removing the Evd.diff function.Gravatar Pierre-Marie Pédrot2014-10-27
|
* Removing the Evd.merge function.Gravatar Pierre-Marie Pédrot2014-10-27
| | | | Its semantics was dubious, and it was not used anymore anyway.
* This commit introduces changes in induction and destruct.Gravatar Hugo Herbelin2014-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main change is that selection of subterm is made similar whether the given term is fully applied or not. - The selection of subterm now works as follows depending on whether the "at" is given, of whether the subterm is fully applied or not, and whether there are incompatible subterms matching the pattern. In particular, we have: "at" given | subterm fully applied | | incompatible subterms | | | Y Y - it works like in 8.4 Y N - this was broken in 8.4 ("at" was ineffective and it was finding all subterms syntactically equal to the first one which matches) N Y Y it now finds all subterms like the first one which matches while in 8.4 it used to fail (I hope it is not a too risky in-draft for a semantics we would regret...) (e.g. "destruct (S _)" on goal "S x = S y + S x" now selects the two occurrences of "S x" while it was failing before) N Y N it works like in 8.4 N N - it works like in 8.4, selecting all subterms like the first one which matches - Note that the "historical" semantics, when looking for a subterm, to select all subterms that syntactically match the first subterm to match the pattern (looking from left to right) is now internally called "like first". - Selection of subterms can now find the type by pattern-matching (useful e.g. for "induction (nat_rect _ _ _ _)") - A version of Unification.w_unify w/o any conversion is used for finding the subterm: it could be easily replaced by an other matching algorithm. In particular, "destruct H" now works on a goal such as "H:True -> x<=y |- P y". Secondary change is in the interpretation of terms with existential variables: - When several arguments are given, interpretation is delayed at the time of execution - Because we aim at eventually accepting "edestruct c" with unresolved holes in c, we need the sigma obtained from c to be an extension of the sigma of the tactics, while before, we just type-checked c independently of the sigma of the tactic - Finishing the resolution of evars (using type classes, candidates, pending conversion problems) is made slightly cleaner: it now takes three states: a term is evaluated in state sigma, leading to state sigma' >= sigma, with evars finally solved in state sigma'' >= sigma'; we solve evars in the diff of sigma' and sigma and report the solution in sigma'' - We however renounce to give now a success semantics to "edestruct c" when "c" has unresolved holes, waiting instead for a decision on what to do in the case of a similar eapply (see mail to coqdev). An auxiliary change is that an "in" clause can be attached to each component of a "destruct t, u, v", etc. Incidentally, make_abstraction does not do evar resolution itself any longer.
* Add more primitives to the [Monad.Make] arguments.Gravatar Arnaud Spiwack2014-10-22
| | | | For optimisation purposes.
* Dead code.Gravatar Hugo Herbelin2014-10-21
|
* Refine: proper scoping of the future goals.Gravatar Arnaud Spiwack2014-10-16
| | | | In my first attempt I just dropped all future goals before starting a refinement. This was done for simplicity but is incorrect in general. In this version the future goals which are not introduced by the particular instance of refine are kept for future use.
* Move the handling of the principal evar from refine to evd.Gravatar Arnaud Spiwack2014-10-16
| | | | | | See previous commit for more discussion. Changed the name from "main" to "principal" because I find "main" overused, and because the name was only introduced yesterday anyway.
* Move the handling a new evars from the [Proofview.Refine] module to [Evd].Gravatar Arnaud Spiwack2014-10-16
| | | | | | | | That way, everything in the code of pretying is made "refine"-aware. Making the abstraction stonger and integration of pretyping with interactive proof more direct. It might create goals in a slightly different goal order in the (user level) refine tactic. Because now, the [update] primitive which used to infer an order from an [evar_map] now has the order fixed by the successive declaration with [Evarutil.new_evar] (and similar). It probably coincides, though. Following a suggestion by Hugo.
* Evd: a few comments to document the increasingly wide internal [evar_map] type.Gravatar Arnaud Spiwack2014-10-16
|
* Evd: remove/update obsolete comments.Gravatar Arnaud Spiwack2014-10-16
|
* Adding a tactic which fails if one of the goals under focus is dependent in ↵Gravatar Hugo Herbelin2014-10-13
| | | | another one.
* Add debug printers for projections, fix printing of evar constraintsGravatar Matthieu Sozeau2014-10-10
| | | | and unsatisfiable constraints which were not done in the right environment.
* Fixing ennoying warning about evars named ?23 and so on.Gravatar Hugo Herbelin2014-10-03
|
* Work around issues with FO unification trying to unify terms ofGravatar Matthieu Sozeau2014-10-02
| | | | | | | | | potentially different types, resulting in ill-typed terms due to eta. Projection expansion now fails gracefully on retyping errors. The proper fix to unification, checking that the heads for FO have unifiable types, is currently too strong, adding unnecessary universe constraints, so it is disabled for now. It might be quite expensive too also it's not noticeable on the stdlib.
* Seeing IntroWildcard as an action intro pattern rather than as a naming patternGravatar Hugo Herbelin2014-09-30
| | | | | | | | | | (the action is "clear"). Added subst_intropattern which was missing since the introduction of ApplyOn intro patterns. Still to do: make "intros _ ?id" working without interferences when "id" is precisely the internal name used for hypotheses to discard.
* Add syntax for naming new goals in refine: writing ?[id] instead of _Gravatar Hugo Herbelin2014-09-30
| | | | | | | | will name the goal id; writing ?[?id] will use the first fresh name available based with prefix id. Tactics intro, rename, change, ... from logic.ml now preserve goal name; cut preserves goal name on its main premise.
* Merging some functions from evarutil.ml/evd.ml.Gravatar Hugo Herbelin2014-09-29
| | | | | | | | | | | | | - Removed collect_evars which does not consider instance (use evars_of_term instead). - Also removed evars_of_evar_info which did not filter context (use evars_of_filterered_evar_info instead). This is consistent with printing goal contexts in the filtered way. Anyway, as of today, afaics goals filters are trivial because (if I interpret evarutil.ml correctly), evars with non-trivial filter necessarily occur in a conv pb. Conversely, conv pbs being solved when tactics are called, there should not be an evar used as a goal with a non-trivial filter.