aboutsummaryrefslogtreecommitdiffhomepage
Commit message (Collapse)AuthorAge
* Fixing a bug in the presence of let-in in inductive arity.Gravatar Hugo Herbelin2014-10-20
|
* Revert "Fixing a loop in proof reconstruction for congruence (#2447)."Gravatar Hugo Herbelin2014-10-17
| | | | | | | committed by mistake. The message pretended to have a fix which is only superficially a fix. The problem is more complex. This reverts commit 251218905daea0838a3738466afa1c278bb3e81b.
* Revert "Essai où assert_style n'est utilisé que si pas visuellement une ↵Gravatar Hugo Herbelin2014-10-17
| | | | | | équation;" which was committed by mistake. This reverts commit a53b44aa042cfded28c34205074f194de7e2e4ee.
* Now printing "now a keyword" only in verbose mode.Gravatar Hugo Herbelin2014-10-17
|
* When facing problem ?id = ?id' in resolution of return predicate,Gravatar Hugo Herbelin2014-10-17
| | | | | | early call the standard resolution function which e.g. does restriction and maybe solve the problem if pattern-like, instead of postponing the problem.
* Experimental printing of the signature of open evars in Check.Gravatar Hugo Herbelin2014-10-17
|
* New experimental heuristic printing strategy for evar instances: WeGravatar Hugo Herbelin2014-10-17
| | | | | | | | | don't print bindings of the form "x:=x" unless there is also a binding "x':=x". Otherwise said, if a variable occurs several time, the binding where it occurs under the form "x:=x" is printed anyway. This should help to understand where the instance is non trivial while still not obfuscating display in goals with very long list of uninteresting trivial instances.
* Re-displaying evar instances in debugger.Gravatar Hugo Herbelin2014-10-17
|
* Fixing a loop in proof reconstruction for congruence (#2447).Gravatar Hugo Herbelin2014-10-17
| | | | | | | | | | | | | | Proofs of C t1..tn+1 = C t1..tn+1, even when the terms were syntactically the same, were built by composition of a proof of C t1..tn = C t1..tn with a proof of reflexivity of tn+1. The latter was reduced to showing C t1..tn = C u1..un for C u1..un the canonical representant of C t1..tn in its congruence class. But if some pair ti=ui was derivable by injectivity of the constructor C, it might go back to find a proof of C t1..tn+1 = C t1..tn+1 again, while a simple reflexivity proof was enough here. Not sure that the fix prevents any further loop in this part of the code though.
* Essai où assert_style n'est utilisé que si pas visuellement une équation;Gravatar Hugo Herbelin2014-10-17
|
* More fallout from elisp renameGravatar Anders Kaseorg2014-10-16
| | | | | | | | | | Commit 3e972b3ff8e532be233f70567c87512324c99b4e renamed coq.el, coq-db.el, coq-syntax.el to gallina.el, gallina-db.el, gallina-syntax.el without fixing up any of the references. Commit 30b58d43e48569afb50a35d3915ec7d453a61f5d only fixed up some of them. Here are some more (hopefully all of them). Signed-off-by: Anders Kaseorg <andersk@mit.edu>
* Relaxing again the test on types of replacements in tactic changeGravatar Hugo Herbelin2014-10-16
| | | | | | | | | | | | | | | | | | | | | | (continuation of 3087e0012eb12833a79b and 1f05decaea97f1dc). It may be the case that the new expression lives in a higher sorts and the context where it is substituted in supports it. So, it is too strong to expect that, when the substituted objects are types, the sort of the new one is smaller than the sort of the original one. Consider e.g. Goal @eq Type nat nat. change nat with (@id Type nat). which is a correct replacement, even if (id Type nat) is in a higher sort. Introducing typing in "contextually" would be a big change for a little numbers of uses, so we instead (hackily) recheck the whole term (even though typing with evars uses evar_conv which accept to unify Type with Set, leading to wrongly accept "Goal @eq Set nat nat. change nat with (@id Type nat).". Evar conv is however rejecting Prop=Type.)
* In convert_concl/convert_hyp: nf_enter -> enter.Gravatar Hugo Herbelin2014-10-16
| | | | (Maybe one of the source of inefficiency introduced on Oct 9 - see e.g. CoLoR.)
* Revert "Naming main goal "Main""Gravatar Hugo Herbelin2014-10-16
| | | | (More thinking needed)
* Refactoring proofview: make the definition of the logic monad polymorphic.Gravatar Arnaud Spiwack2014-10-16
| | | | | | Makes the monad more flexible as it will be easier to add new components to the concrete state of the tactic monad. The Proofview module is also organised in a more abstract way with dedicated submodules to access various parts of the state or writer.
* Refresh to avoid algebraic universes on the right.Gravatar Matthieu Sozeau2014-10-16
|
* Fix test-suite scripts.Gravatar Matthieu Sozeau2014-10-16
|
* Bug fixed by Hugo.Gravatar Matthieu Sozeau2014-10-16
|
* Grab Existential Variables: restore the goal order from v8.4.Gravatar Arnaud Spiwack2014-10-16
| | | | Changes in the implementation details had unwittingly changed the order in which Grab Existential Variables displayed the goals.
* Proofview: cleanup: no more reference to Goal.goal.Gravatar Arnaud Spiwack2014-10-16
|
* Put evars remaining after a tactic on the shelf.Gravatar Arnaud Spiwack2014-10-16
| | | | Uses the new architecture which allows to keep track of all new evars. The [future_goals] are flushed at the end of the tactics, the [principal_future_goal] is ignored.
* 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.
* Goal: remove [advance] from the API.Gravatar Arnaud Spiwack2014-10-16
| | | | Now [Goal] only contains a few helpers.
* Proofview: remove unused [refresh_sigma] compatibility primitive.Gravatar Arnaud Spiwack2014-10-16
|
* Goal: remove some functions from the compatibility layer.Gravatar Arnaud Spiwack2014-10-16
| | | | The rest will take more work.
* Goal: remove most of the API (make [Goal.goal] concrete).Gravatar Arnaud Spiwack2014-10-16
| | | | We are left with the compatibility layer and a handful of primitives which require some thought to move.
* Make [Goal.goal] be exactly [Evar.t].Gravatar Arnaud Spiwack2014-10-16
| | | | | First step in removing the [Goal] module whose code is now essentially legacy. Removes the cache attached to a goal, which was used to avoid unnecessary [nf_evar]. May have a performance cost, which is to be fixed later.
* Goal: remove dead code.Gravatar Arnaud Spiwack2014-10-16
|
* Expose Proofview.Refine.with_type in the API.Gravatar Arnaud Spiwack2014-10-16
|
* Proofview.Refine: remove the handle type, and simplify the API.Gravatar Arnaud Spiwack2014-10-16
| | | | | | Now, usual function from Evarutil are used to define evars instead of the variants from Proofview.Refine. The [update] primitive which tried to patch the difference between pretyping functions and the refine primitive is now replaced by the identity function.
* 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
|
* Proofview.Refine: delay the marking of new evars as goals from [new_evar] to ↵Gravatar Arnaud Spiwack2014-10-16
| | | | | | [refine]. This makes [new_evar] closer to be a mere wrapper around [Evarutil.new_evars]. Will allow restructuring of the refinement interface.
* Proofview: small optimisation/simplification.Gravatar Arnaud Spiwack2014-10-16
|
* ConstructiveEpsilon: simplify the before_witness type using non-uniform ↵Gravatar Arnaud Spiwack2014-10-16
| | | | parameters.
* Adding a timeout to bug #2447.Gravatar Pierre-Marie Pédrot2014-10-15
|
* To stay closer to non-primitive projections, only unfold primitiveGravatar Matthieu Sozeau2014-10-15
| | | | | projections in cbv when delta _and_ beta flags are set. Add test-suite file for bug 3700 too.
* Make use of unfolded primitive projections when elaborating match on aGravatar Matthieu Sozeau2014-10-15
| | | | primitive record.
* Fix ill-typed debugging functionGravatar Matthieu Sozeau2014-10-15
|
* Fix for bug #3618.Gravatar Matthieu Sozeau2014-10-15
| | | | | Fix typeclass resolution which was considering as subgoals of a tactic application unrelated pre-existing undefined evars.
* Remaining tactics of the Auto module were put in the monad.Gravatar Pierre-Marie Pédrot2014-10-15
|
* Closed bug 3710.Gravatar Matthieu Sozeau2014-10-15
|
* Bug 3692 is fixed.Gravatar Matthieu Sozeau2014-10-15
|
* Bug 3628 is fixed.Gravatar Matthieu Sozeau2014-10-15
|
* Fix test-suite files which failed due to usage of $(admit)$ whichGravatar Matthieu Sozeau2014-10-15
| | | | now fails with Error: Already an existential evar of name Main
* Fix bug 3637.Gravatar Matthieu Sozeau2014-10-15
|
* Reenable FO unification of primitive projections and their eta-expandedGravatar Matthieu Sozeau2014-10-15
| | | | | | forms in evarconv and unification, as well as fallback to first-order unification when eta for constructors fail. Update test-suite file 3484 to test for the FO case in evarconv as well.
* Fix test-suite file after moving back to using C as the nameGravatar Matthieu Sozeau2014-10-15
| | | | of the record binder for Class C's projections.