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

Start a Tactics V2 #2960

Merged
merged 47 commits into from
Jun 19, 2023
Merged

Start a Tactics V2 #2960

merged 47 commits into from
Jun 19, 2023

Conversation

mtzguido
Copy link
Member

@mtzguido mtzguido commented Jun 12, 2023

This PR introduces a new version of the tactics engine, with differences to (mostly) the representation of terms. The change is heavily disruptive to pretty much everything, so we are staging it by maintaining a .V1 namespace of Tactics and Reflection, which retains exactly the previous behaviour, and a V2 with new changes. V2, for now, has to be explicitly asked for by open FStar.Tactics.V2 or any submodule thereof.

The two versions can interoperate, the underlying effect is the same, but the relevant view types and primitives can be different. Some files are totally agnostic to the version, such as FStar.Tactics.SMT and FStar.Tactics.Visit (which is now implemented with V2, but just exposes visit_tm : (term -> Tac term) -> term -> Tac term),

V2 is very explicit about opening/closing names, freshness, etc. This is now all implemented in userspace (FStar.Tactics.NamedView), and marked as a plugin so it runs fast.

Another significant change is the autogeneration of embeddings for most inductive types, so many more functions can be easily made into plugins. Also typeclasses are moved higher up in the dependency chain and even used within tactic libraries (FStar.Tactics.MApply.fst).

For now, I think V2 should be considered experimental and subject to change, but I would like to get this into the repo as it's a big change that could diverge.

Karamel needs a tiny patch to ignore a new module, FStar.Syntax.Syntax, in ulib/ (which is an interface for the compiler's FStar.Syntax.Syntax). We may move all of the F* compiler sources into the FStar.Compiler namespace to make this easier to maintain, but not on this PR.

I have a steel branch that works with V2.
For hacl-star I haven't yet ported to V2, but confirmed that it works as before with V1.
Will post an everest green later.

@mtzguido
Copy link
Member Author

Everest run will be here https://github.com/mtzguido/everest/actions/runs/5238573630

@mtzguido
Copy link
Member Author

mtzguido commented Jun 13, 2023

Some things to think about:

  • I think typeclass resolution can be abstracted behind an interface if it's always used as a plugin. This would reduce the dependencies imposed into clients, which can be pretty huge. See this:
    depgraph-FStar.Tactics.Typeclasses.fst.pdf
  • For plugins, it may be useful to have a check that will ignore the compiled plugin if the underlying term changed (we could check the hash, transitively across dependencies). It can reduce shots in the foot, but should also be optional using the old one can be useful (e.g. bootstrapping a tiny change to typeclasses).
  • Automatically loading a plugin right after typechecking it should not be super hard.

@mtzguido
Copy link
Member Author

This PR also introduces an FStar.Tactics.SMT module with tactics to tweak the SMT context of individual assertions, like so:

      assert (loc_disjoint (loc_union l (loc_addresses true r0 (Set.singleton a0))) (loc_of_aloc b))
          by (let open FStar.Tactics.V2.Builtins in
              let open FStar.Tactics.SMT in
              set_rlimit 64;
              set_options "--z3cliopt 'smt.qi.eager_threshold=5'";
              ())

there are also getters/setters for fuel/ifuel.

mtzguido added 21 commits June 14, 2023 17:09
Port change to `refl_typing_builtin_wrapper` to V2 as well.
We were getting double seals
For documentation and reducing dependencies. Also more things marked as
plugins.
With some exceptions, but it's easier if the default is to
extract modules here.
This allows to untie some dependency knots in the compiler, mostly
in support of using typeclasses/tactics in src/. This way, the
users of tactics in src/ (say defining a to_string instance in
FStar.Syntax.Print) could only depend on FStar.Stubs.Tactics.Builtins,
and not on the *actual* builtins with the implementations, which would
be a cycle.

This works as long as the dependency is only for tactic execution, as
the extracted code will not have such dependency.
@mtzguido mtzguido merged commit 52f5fa9 into FStarLang:master Jun 19, 2023
@mtzguido mtzguido deleted the guido_syntax branch June 19, 2023 18:37
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