aboutsummaryrefslogtreecommitdiff
path: root/vernac/comProgramFixpoint.mli
AgeCommit message (Collapse)Author
2020-11-02attribute #[using] for Definition and FixpointEnrico Tassi
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-06-26[declare] [api] Removal of duplicated type aliases.Emilio Jesus Gallego Arias
2020-05-07[declare] Merge DeclareDef into DeclareEmilio Jesus Gallego Arias
The API in `DeclareDef` should become the recommended API in `Declare`. This greatly reduces the exposure of internals; we still have a large offender in `Lemmas` but that will be taken care of in the next commit; effectively removing quite some chunks from `declare.mli`. This PR originally introduced a dependency cycle due to: - `Declare`: uses `Vernacexpr.decl_notation list` - `Vernacexpr`: uses `ComHint.hint_expr` - `ComHint`: uses `Declare.declare_constant` This is a real cycle in the sense that `ComHint` would have also move to `DeclareDef` in the medium term. There were quite a few ways to solve it, we have chosen to move the hints ast to `Vernacexpr` as it is not very invasive and seems consistent with the current style. Alternatives, which could be considered at a later stage are for example moving the notations AST to `Metasyntax`, having `Declare` not to depend on `Vernacexpr` [which seems actually a good thing to do in the medium term], reworking notation support more deeply...
2020-03-18Update headers in the whole code base.Théo Zimmermann
Add headers to a few files which were missing them.
2019-07-23[vernacexpr] Remove duplicate fixpoint record.Emilio Jesus Gallego Arias
We continue over the previous commit and remove redundant `structured_fixpoint_expr` record in favor of the one used in the AST. This removes some term-shuffling, tho we still have discrepancies related to adjustments on the recursive annotation.
2019-07-23[vernacexpr] Refactor fixpoint AST.Emilio Jesus Gallego Arias
We turn the tuples used for (co)-fixpoints into records, cleaning up their users. More cleanup is be possible, in particular a few functions can now shared among co and fixpoints, also `structured_fixpoint_expr` could like be folded into the new record. Feedback on the naming of the records fields is welcome. This is a step towards cleaning up code in `funind`, as it is the main consumer of this data structure, as it does quite a bit of fixpoint manipulation. cc: #6019
2019-06-24[api] Move `locality` from `library` to `vernac`.Emilio Jesus Gallego Arias
This datatype does belong to this layer.
2019-06-24[lemmas] [proof] Split proof kinds into per-layer components.Emilio Jesus Gallego Arias
We split `{goal,declaration,assumption}_kind` into their components. This makes sense as each part of this triple is handled by a different layer, namely: - `polymorphic` status: necessary for the lower engine layers; - `locality`: only used in `vernac` top-level constants - `kind`: merely used for cosmetic purposes [could indeed be removed / pushed upwards] We also profit from this refactoring to add some named parameters to the top-level definition API which is quite parameter-hungry. More refactoring is possible and will come in further commits, in particular this is a step towards unifying the definition / lemma save path.
2017-12-17[vernac] Split `command.ml` into separate files.Emilio Jesus Gallego Arias
Over the time, `Command` grew organically and it has become now one of the most complex files in the codebase; however, its functionality is well separated into 4 key components that have little to do with each other. We thus split the file, and also document the interfaces. Some parts of `Command` export tricky internals to use by other plugins, and it is common that plugin writers tend to get confused, so we are more explicit about these parts now. This patch depends on #6413.