aboutsummaryrefslogtreecommitdiff
path: root/vernac/vernacstate.mli
AgeCommit message (Collapse)Author
2020-11-20[stm] [declare] Remove pinfo internals hack.Emilio Jesus Gallego Arias
After the previous commit, the stm should correctly pass proof information, thus we make `proof_object` carry it removing a bunch of internal code.
2020-08-31Update update_global_env usageGaëtan Gilbert
- take just a ugraph instead of the whole env - rename to update_sigma_univs - push global env lookup a bit further up - fix vernacinterp call to update all surrounding proofs, not just the top one - flip argument order for nicer partial applications
2020-08-27[state] A few nits after consolidation of state.Emilio Jesus Gallego Arias
We remove some dead aliases and add some documentation to the interface file.
2020-07-08[obligations] Functionalize Program stateEmilio Jesus Gallego Arias
In our quest to unify all the declaration paths, an important step is to account for the state pertaining to `Program` declarations. Whereas regular proofs keep are kept in a stack-like structure; obligations for constants defined by `Program` are stored in a global map which is manipulated by almost regular open/close proof primitives. We make this manipulation explicit by handling the program state functionally, in a similar way than we already do for lemmas. This requires to extend the proof DSL a bit; but IMO changes are acceptable given the gain. Most of the PR is routine; only remarkable change is that the hook is called explicitly in `finish_admitted` as it had to learn about the different types of proof_endings. Note that we could have gone deeper and use the type system to refine the core proof type; IMO it is still too preliminary so it is better to do this step as an intermediate one towards a deeper unification.
2020-07-01[state] Consolidate state handling in VernacstateEmilio Jesus Gallego Arias
After #12504 , we can encapsulate and consolidate low-level state logic in `Vernacstate`, removing `States` which is now a stub. There is hope to clean up some stuff regarding the handling of low-level proof state, by moving both `Evarutil.meta_counter` and `Evd.evar_counter_summary` into the proof state itself [obligations state is taken care in #11836] , but this will take some time.
2020-06-26[declare] Improve logical code orderEmilio Jesus Gallego Arias
Now that the interface has mostly stabilized, we move code around to respect internal dependency order. This will allow us to start sharing more code in the 4 principal cases, and also paves the way for the full merging of obligations and the removal of the Proof_ending type in favor of stronger type abstraction.
2020-06-26[declare] Improve organization of proof/constant information.Emilio Jesus Gallego Arias
We unify information about constants so it is shared among all the paths [interactive, NI, obligations]. IMHO the current setup looks pretty good, with information split into a per-constant record `CInfo.t` and variables affecting mutual definitions at once, which live in `Info.t`. Main information outside our `Info` record is `opaque`, which is provided at different moments in several cases. There are a few nits regarding interactive proofs, which will go away in the next commits.
2020-06-26[declare] [api] Removal of duplicated type aliases.Emilio Jesus Gallego Arias
2020-06-26[declare] Move proof information to declare.Emilio Jesus Gallego Arias
At this point the record in lemmas was just a stub; next commit will stop exposing the internals of mutual information, and pave the way for the refactoring of `Info.t` handling in the Declare interface.
2020-04-15[declare] Rename `Declare.t` to `Declare.Proof.t`Emilio Jesus Gallego Arias
This still needs API cleanup but we defer it to the moment we are ready to make the internals private.
2020-04-15[proof] Merge `Proof_global` into `Declare`Emilio Jesus Gallego Arias
We place creation and saving of interactive proofs in the same module; this will allow to make `proof_entry` private, improving invariants and control over clients, and to reduce the API [for example next commit will move abstract declaration into this module, removing the exported ad-hoc `build_constant_by_tactic`] Next step will be to unify all the common code in the interactive / non-interactive case; but we need to tweak the handling of obligations first.
2020-03-31[proof] [stm] Force `opaque` in `close_future_proof`Emilio Jesus Gallego Arias
Following an observation by Enrico Tassi, we remove the `opaque` parameter from `close_future_proof`, it should never be called with transparent constants. We will enforce this thru typing at the proof layer soon.
2020-03-31[proof] Split return_proof in partial and regular versions.Emilio Jesus Gallego Arias
This is a small refactoring as these two functions behave very differently and the invariants are quite different, in fact regular `return_proof` should not be exported but be part of close proof, but there is small use in the STM still.
2020-03-31[proof] Split delayed and regular proof closing functions, part IIEmilio Jesus Gallego Arias
We make the types of the delayed / non-delayed declaration path different, as the latter is just creating futures that are forced right away. TTBOMK the new code should behave identically w.r.t. old one, modulo the equation `Future.(force (from_val x)) = x`. There are some questions as what the code is doing, but in this PR I've opted to keep the code 100% faithful to the original one, unless I did a mistake.
2020-03-18Update headers in the whole code base.Théo Zimmermann
Add headers to a few files which were missing them.
2019-06-25[lemmas] Move `Stack` out of Lemmas.Emilio Jesus Gallego Arias
We move the stack of open lemmas from `Lemmas` to `Vernacstate`. The `Lemmas` module doesn't deal with stacked proofs, so the stack can be moved to to the proper place; this reduces the size of the API. Note that `Lemmas` API is still quite imperative, it would be great if we would return some more information on close proof, for example about the global environment parts that were modified.
2019-06-24[lemmas] Turn Lemmas.info into a proper type with constructor.Emilio Jesus Gallego Arias
Lemmas.info was a bit out of hand, as well as the parameters to the `start_*` family. Most of the info is not needed and should hopefully remain constrained to special cases, most callers only set the hook, and obligations should be better served by a `start_obligation` function soon.
2019-06-24[lemmas] Reify info for implicits, univ_decls, prepare for rec_thms.Emilio Jesus Gallego Arias
Key information about an interactive lemma proof was stored as a closure on an ad-hoc hook, then later made available to the hook closing actions. Instead, we put this information in the lemma state and incorporate these declarations into the normal save path. We prepare to put the information about rec_thms in the state too.
2019-06-20Merge PR #9645: [proof] Remove terminator type, unifying regular and ↵Pierre-Marie Pédrot
obligation ones. Ack-by: ejgallego Ack-by: gares Reviewed-by: ppedrot
2019-06-17Update ml-style headers to new year.Théo Zimmermann
2019-06-17[proof] drop parameter from terminator typeEmilio Jesus Gallego Arias
This makes the type of terminator simpler, progressing towards its total reification.
2019-06-17[proofs] Store hooks in the proof object.Emilio Jesus Gallego Arias
As of now, hooks were stored in the terminators as closures, we place them instead in the proof object and are thus passed back at proof closing time. This helps towards the reification and unification of terminators.
2019-06-09[proof] Uniformize Proof_global APIEmilio Jesus Gallego Arias
We rename modify to map [more in line with the rest of the system] and make the endline function specific, as it is only used in one case.
2019-06-09[save_proof] Make terminator API internal.Emilio Jesus Gallego Arias
We refactor the terminator API to make it more internal. Indeed we remove `set_terminator` and `get_terminator` is only there due to access to internals in the STM `save_proof` path by the infamous `?proof` parameter. After this only 2 non-standard terminators remain: obligations and derive. We will refactor those in next PRs.
2019-06-09[proof] Move proofs that have an associated constant to `Lemmas`Emilio Jesus Gallego Arias
The main idea of this PR is to distinguish the types of "proof object" `Proof_global.t` and the type of "proof object associated to a constant, the new `Lemmas.t`. This way, we can move the terminator setup to the higher layer in `vernac`, which is the one that really knows about constants, paving the way for further simplification and in particular for a unified handling of constant saving by removal of the control inversion here. Terminators are now internal to `Lemmas`, as it is the only part of the code applying them. As a consequence, proof nesting is now handled by `Lemmas`, and `Proof_global.t` is just a single `Proof.t` plus some environmental meta-data. We are also enable considerable simplification in a future PR, as this patch makes `Proof.t` and `Proof_global.t` essentially the same, so we should expect to handle them under a unified interface.
2019-06-04Rename Proof_global.{pstate -> t}Gaëtan Gilbert
2019-06-04Rename Proof_global.{t -> stack}Gaëtan Gilbert
2019-06-04coqpp: add new ![] specifiers for structured proof interactionGaëtan Gilbert
![proof_stack] is equivalent to the old meaning of ![proof]: the body has type `pstate:Proof_global.t option -> Proof_global.t option` The other specifiers are for the following body types: ~~~ ![open_proof] `is_ontop:bool -> pstate` ![maybe_open_proof] `is_ontop:bool -> pstate option` ![proof] `pstate:pstate -> pstate` ![proof_opt_query] `pstate:pstate option -> unit` ![proof_query] `pstate:pstate -> unit` ~~~ The `is_ontop` is only used for the warning message when declaring a section variable inside a proof, we could also just stop warning. The specifiers look closely related to stm classifiers, but currently they're unconnected. Notably this means that a ![proof_query] doesn't have to be classified QUERY. ![proof_stack] is only used by g_rewrite/rewrite whose behaviour I don't fully understand, maybe we can drop it in the future. For compat we may want to consider keeping ![proof] with its old meaning and using some new name for the new meaning. OTOH fixing plugins to be stricter is easier if we change it as the errors tell us where it's used.
2019-04-09[api] [proof] Alert users that `Vernacstate.Proof_global` is not to be used.Emilio Jesus Gallego Arias
We alert users that `Vernacstate.Proof_global` is a Coq internal module and should not be used to workaround lack of state threading.
2019-03-27[vernac] [stm] Tweak `with_fail` and hopefully fix the semantics.Emilio Jesus Gallego Arias
We try to do a bit of cleanup for the `with_fail` function, this still is delicate code.
2019-03-27[vernac] Adapt to removal of imperative proof state.Emilio Jesus Gallego Arias
2019-01-24[STM] explicit handling of parsing statesEnrico Tassi
DAG nodes hold now a system state and a parsing state. The latter is always passed to the parser. This paves the way to decoupling the effect of commands on the parsing state and the system state, and hence never force to interpret, say, Notation. Handling proof modes is now done explicitly in the STM, not by interpreting VernacStartLemma. Similarly Notation execution could be split in two phases in order to obtain a parsing state without fully executing it (that requires executing all commands before it). Co-authored-by: Maxime Dénès <maxime.denes@inria.fr> Co-authored-by: Emilio Jesus Gallego Arias <e+git@x80.org>
2018-12-13Move shallow state logic to the function preparing state for workersMaxime Dénès
2018-02-27Update headers following #6543.Théo Zimmermann
2017-11-29[proof] [api] Rename proof types in preparation for functionalization.Emilio Jesus Gallego Arias
In particular `Proof_global.t` will become a first class object for the upper parts of the system in a next commit.
2017-11-22[plugin] Encapsulate modifiers to vernac commands.Emilio Jesus Gallego Arias
This is a continuation on #6183 and another step towards a more functional interpretation of commands. In particular, this should allow us to remove the locality hack.
2017-11-19[plugins] Prepare plugin API for functional handling of state.Emilio Jesus Gallego Arias
To this purpose we allow plugins to register functions that will modify the state. This is not used yet, but will be used soon when we remove the global handling of the proof state.