aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-11-02Small change to the IO monad interface: [val ref : 'a -> 'a ref t]aspiwack
It doesn't matter much, it's simply a matter of aesthetic, so that all functions in the interface of [Monads.IO] are pure ([IO.run] being the only impure function but it's not part of the generic interface). git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16974 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02A whole new implemenation of the refine tactic.aspiwack
It now uses the same algorithm as pretyping does. This produces pretty weird goal when refining pattern matching terms. Modification of the pattern matching compilation algorithm are pending, hence I will let it be so for now. The file Zsqrt_compat.v has two temporary [Admitted] related to this issue. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16973 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02A newly introduced variable inside a named context is no longer α-renamed.aspiwack
Instead, in case of collision, the older name is substituted for a fresh one. It should also be made inaccessible from the user, but I'll leave this for later. The goal is to guarantee that [refine (fun x => _)] introduces a binder named [x]. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16972 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Clean-up: removed redundant notations (>>-) and (>>--) from Proofview.Notations.aspiwack
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16971 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Bases tactics on an IO monad.aspiwack
It allowed to restore the timeout tactics. It also prepares for the debugging mechanism to be restored. ['a IO.t] is just [unit -> 'a]. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16970 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Getting rid of Goal.here, and all the related exceptions and combinators.aspiwack
It was a bad idea. The new API based on lists seems more sensible. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16969 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Uses Proofview.tclEXTEND more sparingly.aspiwack
It is used where failures can be caughts (tclORELSE, tclTRY, …) rather than at each tclTHEN. Hopefully avoiding making things a bit less slow. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16968 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Makes the new Proofview.tactic the basic type of Ltac.aspiwack
On the compilation of Coq, we can see an increase of ~20% compile time on my completely non-scientific tests. Hopefully this can be fixed. There are a lot of low hanging fruits, but this is an iso-functionality commit. With a few exceptions which were not necessary for the compilation of the theories: - The declarative mode is not yet ported - The timeout tactical is currently deactivated because it needs some subtle I/O. The framework is ready to handle it, but I haven't done it yet. - For much the same reason, the ltac debugger is unplugged. It will be more difficult, but will eventually be back. A few comments: I occasionnally used a coercion from [unit Proofview.tactic] to the old [Prooftype.tactic]. It should work smoothely, but loses any backtracking information: the coerced tactics has at most one success. - It is used in autorewrite (it shouldn't be a problem there). Autorewrite's code is fairly old and tricky - It is used in eauto, mostly for "Hint Extern". It may be an issue as time goes as we might want to have various success in a "Hint Extern". But it would require a heavy port of eauto.ml4 - It is used in typeclass eauto, but with a little help from Matthieu, it should be easy to port the whole thing to the new tactic engine, actually simplifying the code. - It is used in fourier. I believe it to be inocuous. - It is used in firstorder and congruence. I think it's ok. Their code is somewhat intricate and I'm not sure they would be easy to actually port. - It is used heavily in Function. And honestly, I have no idea whether it can do harm or not. Updates: (11 June 2013) Pierre-Marie Pédrot contributed the rebase over his new stream based architecture for Ltac matching (r16533), which avoid painfully and expensively working around the exception-throwing control flow of the previous API. (11 October 2013) Rebasing over recent commits (somewhere in r16721-r16730) rendered a major bug in my implementation of Tacticals.New.tclREPEAT_MAIN apparent. It caused Field_theory.v to loop. The bug made rewrite !lemma, rewrite ?lemma and autorewrite incorrect (tclREPEAT_MAIN was essentially tclREPEAT, causing rewrites to be tried in the side-conditions of conditional rewrites as well). The new implementation makes Coq faster, but it is pretty much impossible to tell if it is significant at all. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16967 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-11-02Closure: fix an issue with r16959 spotted by Matthieuletouzey
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16966 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Mod_subst.update_delta_resolver : avoid loosing Inline(_,Some _)letouzey
This commit should fix the contrib ProjectiveGeometry This update_delta_resolver is in fact a sequential composition (resolver1 then resolver2). The earlier version was strangely favoring the bindings coming from resolver2 over the bindings coming from (resolver1 chained with resolver2). So any inlining information stored in resolver1 could be discarded savagely. Apparently, this situation wasn't occurring in practice until recently, when I started to do lots of Mod_subst.join for improving the size of modular libobjects in the vo's. So, when combining two resolvers now : - Inline(_,None) is the weakest information, it's just a declaration that we intend to inline this kn someday if possible (i.e. when we'll have a transparent implementation for it). This kind of Inline is only relevant inside a module type. - Equiv(_) should only appear in modules (after some Include) so it should be ok if it takes precedence over any Inline(_,None) remaining in the other resolver. - Inline(_,Some _) is there after functor application (cf inline_delta_resolver) : we've done the inlining, so we don't care anymore about other Equiv(_) or Inline(_,None) informations about this kn, since we have anyway a new body for it. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16965 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Fixing Kerpair.hash. Since the beginning, it dit not respect the typeppedrot
equality, maybe impeding hashconsing. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16964 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Future: better doc + restore ~pure optimizationgareuselesinge
This optimization was undone because the kernel type checking was not a pure functions (it was accessing the conv_oracle state imperatively). Now that the conv_oracle state is part of env, the optimization can be restored. This was the cause of the increase in memory consumption, since it was forcing to keep a copy of the system state for every proof, even the ones that are not delayed/delegated to slaves. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16963 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31CoqIDE: scroll to the right position if there is an interp errorgareuselesinge
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16962 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Conv_orable made functional and part of pre_envgareuselesinge
But for vm, the kernel should be functional now git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16961 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Efficient filtered functions in Evd. We test that a filter is actuallyppedrot
different from the identity before trying to compute filtered env/hyps. According to profiling, it seems that the filter operation is NEVER taken, that is, all filters that reach toplevel are dummy. There is surely something to do here... git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16960 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-31Avoiding useless allocations in Closure.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16959 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-30Various optimizations of Evd.meta_* functions.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16958 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-30More efficient implementation of [Evd.retract_coercible_metas].ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16957 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Optimization in unification: when checking that the head of a term is anppedrot
evar or a meta, don't reconstruct the whole term. This hopefully saves a lot of useless allocations and computing time. I may have slightly changed the heuristic though, as only evars in front of applications where recognized as such, whereas now this pass through cases and fixpoints. I am walking on thin ice, but the test-suite was OK... git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16956 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Useless array-to-list casts in Unification.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16955 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Do not generate useless argument arrays in whd_* functions.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16954 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Prevent [Evarutil.whd_head_evar] from uselessly reallocating arrays.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16953 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29[Reductionops.append_stack_app]: do not allocate a useless array.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16952 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Revert the two last commits. My bad, I messed up git-svn commands...ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16951 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Profile only when CAMLRUNPARAM is set.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16950 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Printing heap on every processed sentence.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16949 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Sharing identity evar filters.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16948 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Allocation-friendly version of [Pre_env.push_named].ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16947 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29Optimizing universes: tail-rec, allocation friendly [compare_leq].ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16946 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-29- install evar printer for debuggingmsozeau
- make unification try canonical structures before expansion as in evar_conv - add a fast path to evar inversion (patch from B. Ziliani). git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16945 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-28Native compiler: library compilation errors are now non fatal.mdenes
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16944 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-28Evar leak in "absurd" tactic.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16943 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-28Removing Evd.undefined_evars.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16942 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-28Useless array to list conversions in proof/logic.ml.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16941 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-27Removing useless filter allocation in evar construction.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16940 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-27Abstracting evar filter away. The API is not perfect, but better than nothing.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16939 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-27More sharing in Constr.map_with_binders.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16938 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-27Closure optimizations.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16937 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24More monomorphic List.mem + List.assoc + ...letouzey
To reduce the amount of syntactic noise, we now provide a few inner modules Int.List, Id.List, String.List, Sorts.List which contain some monomorphic (or semi-monomorphic) functions such as mem, assoc, ... NB: for Int.List.mem and co we reuse List.memq and so on. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16936 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24inductive.ml : get rid of some obvious (Lazy.force (lazy t))letouzey
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16935 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Rtree : cleanup of the comparing codeletouzey
* Using generic fold functions was unecessarily obscure * No more List.mem and hence indirect use of ocaml generic comparison * Rtree.equiv (former Rtree.compare_rtree) has now a less cryptic semantic... git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16934 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Specializing hash functions for widely used types.ppedrot
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16933 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Restore my version of notation_ops.ml now that List.remove_assoc_f is fixedletouzey
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16932 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Fix the semantic of the new List.remove_assoc_fletouzey
Unlike Ocaml's stdlib List.remove_assoc, I was raising Not_found when the key to remove wasn't there... git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16931 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Oups, repair the compilation (micromega + Morphism_prop)letouzey
It seems I forgot to fully recompile after my last bunch of syntactic changes about List.assoc_f, that weren't so syntactic after all, sorry : - Util isn't used in micromega, hence no List.assoc_f there - There is something wrong in my modifications of Notation_ops that breaks the compilation of Morphism_prop. For the moment I don't see what, so I revert all the modifications of this file git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16930 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Ephemeron: add a function to run a collection cyclegareuselesinge
This is necessary if one wants to check how much memory Coq uses after a collection. The idiom is: Gc.full_major (); Ephemeron.clear (); Gc.full_major (); since the first collection may just put collected ephemerons in a to_be_cleared list that is processed by Ephemeron.get/create/clear. Processing the list may create new garbage (the content of the ephemeron), Hence a new Gc cycle has to be run afterwards. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16929 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24CoqIDE: fix coloring bug when jumping back to the first phrasegareuselesinge
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16928 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Get rid of polymorphic comparison in "plugins/btauto/refl_btauto.ml".xclerc
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16927 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Get rid of polymorphic equality in "checker/subtyping.ml".xclerc
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16926 85f007b7-540e-0410-9357-904b9bb8a0f7
2013-10-24Turn many List.assoc into List.assoc_fletouzey
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16925 85f007b7-540e-0410-9357-904b9bb8a0f7
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-27 16:10:17 +0000