Recursor refactor #1289
Closed
Recursor refactor #1289
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This command, when given a term at first-order type, will symbolically evaluate the term and extract any occurrences of functions mentioned in the given list as fresh variables. The arguments passed to the function are collected together into a tuple and returned together with the fresh variables generated to stand in for those occurrences.
Given a term at first-order type, occurrences of functions that are mentioned in the set of `VarIndex` will be replaced with fresh variables of the return type of the function. The arguments passed to each occurrence are collected and returned in a map.
This distinguishes the two different coercions that can occur, and allows us to track the width of the bitvector type in `VBVToNat`. This is important for term readback in the term model.
where they can be reused more easily.
on opaque values.
This reverts commit 7fb8a52. This has unintended consequences when using these functions as `globalConv` conversion rules. This causes a bunch of conversion rules to not fire.
Previously, these functions were not working correctly when the _types_ of some `ExtCns` values mention some of the `ExtCns` values being abstracted or generalized. Now we are careful to both evaluate inside the types of `ExtCns` values occuring inside the term, as well as making sure that the types of `ExtCns` values in the list are processed properly in the context of the outer values.
This mostly just adds `LocalName` values to functions and Pi types so meaningful names can be round-tripped. We also add a `VTyTerm` constructor to `TValue` for types that cannot be fully evaluated (because they are blocked on a variable, etc).
of the TermModel evaluator.
Remove the `Identity` monad specializations in the simulator.
I think this makes it easier to understand.
|
I will be rebasing this code and resubmitting as more targeted PRs |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is currently in a very rough state. It is a series of refactorings designed to enable a "term model" evaluator. The goal of this evaluator is to provide an evaluation-based simplifier that works directly on saw-core terms and that can gracefully handle all of the constructs appearing in saw-core (including dependent functions).
The technical approach is to use a normalization-by-evaluation technique, which uses the term evaluator to do as much computation as possible, but also allow terms to be treated as opaque, so that they block further evaluation. To make this work properly requires that the simulator keep track of some more information (specifically, the types of values in the evaluation environment). This, in turn, has required some relatively extensive refactoring of how datatype recursors are implemented so that type information can be computed and made available in the correct places without computing it fresh on each recursor evaluation (which proves to be much too expensive).
This draft PR currently exists mostly to exercise the CI tests and ensure that these refactoring steps have not broken or significantly slowed down our large-scale proofs.