Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing the fv_delta field #3272

Merged
merged 8 commits into from
Apr 27, 2024
Merged

Removing the fv_delta field #3272

merged 8 commits into from
Apr 27, 2024

Conversation

mtzguido
Copy link
Member

This PR simplifies somewhat the handling of delta_depths throughout the compiler. Currently, we have an fv_delta : option delta_depth field in every fv, which is mostly set by desugaring (which is a first problem, variables created by tactics usually have this depth wrong). Also, there is a way to compute the delta_depth dynamically from the environment in Env.delta_depth_of_fv, which actually looks at the definition of the variable. But, for some identifiers, it still falls back to the fv_delta field, the reason being that using the legit delta_depth brings many regressions in the form of badly generated VCs (connectives get unfolded) or checking errors (connectives do not get unfolded when it matters, like let f : ~p = return_squash ()).

The desugarer also had a big table of assumed delta_depths, most of which were not right, but which kept the thing working. For some connectives like /\, the desugarer would set the depth to Delta_constant_at_level 1, but a conjunction created by the unifier (e.g. when meeting refinements), would use Delta_constant_at_level 0, so we were in fact mixing different depths for a same given symbol.

--

This PR removes the fv_delta field altogether, and centralizes the definition of what a delta_depth is in the typechecker (as a memoized function). Since the field is gone, the desugarer (and tactics) need not have a clue about delta_depths, so the magic tables are also now gone. This did require a patch in the unifier to handle cases like /\ above gracefully, though: when we're matching types, we do want to unfold /\ (it has a definition, we want to use it for constructive logic); but when matching propositions, such as refinement formulas, we do not. So the unifier now sets an extra flag for each problem stating whether the problem is logical or not, preventing unfolding connectives when so.

The whole thing is still not very pretty, and there are some dubious transformations like this snippet, but it's definitely cleaner and getting a consistent state that passes everest was pretty tricky, so I'd like to merge this as it is.

In preparation of a change to come...
For logical problems, unfolding logical connectives is forbidden
(UnfoldTac)
The unifier will now try to subtype the unit into False via a query,
instead of failing outright.

Also remove duplicate in micro-benchmarks, we check the
correctness of the tests here too.
@mtzguido mtzguido merged commit c9e98c7 into FStarLang:master Apr 27, 2024
2 checks passed
@mtzguido mtzguido deleted the no_fv_delta branch April 27, 2024 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant