Documentation

Mathlib.Tactic.TacticAnalysis

Tactic analysis framework #

In this file we define a framework for analyzing sequences of tactics. This can be used for linting (for instance: report when two rw calls can be merged into one), but it can also be run in a more batch-like mode to report larger potential refactors (for instance: report when a sequence of three or more tactics can be replaced with grind, without taking more heartbeats than the original proof did).

Using the framework #

The framework runs, but does nothing by default (set_option linter.tacticAnalysis false to turn it off completely). Enable the analysis round roundName by enabling its corresponding option: set_option linter.tacticAnalysis.roundName true.

To add a round of analysis called roundName, declare an option linter.tacticAnalysis.roundName, make a definition of type Mathlib.TacticAnalysis.Config and give the Config declaration the @[tacticAnalysis linter.tacticAnalysis.roundName] attribute. Don't forget to enable the option.

Warning #

The ComplexConfig interface doesn't feel quite intuitive and flexible yet and should be changed in the future. Please do not rely on this interface being stable.

The tactic analysis framework hooks into the linter to run analysis rounds on sequences of tactics. This can be used for linting, or in a more batch-like mode to report potential refactors.

Stores the configuration for a tactic analysis pass.

This provides the low-level interface into the tactic analysis framework.

Instances For

    The internal representation of a tactic analysis pass, extending Config with some declaration meta-information.

    Instances For

      Each tactic analysis round is represented by the declaration name for the Config.

      Instances For

        Read a configuration from a declaration of the right type.

        Equations
        • One or more equations did not get rendered due to their size.
        Instances For

          Parse an infotree to find all the sequences of tactics contained within stx.

          We consider a sequence here to be a maximal interval of tactics joined by ; or newlines. This function returns an array of sequences. For example, a proof of the form:

          by
            tac1
            · tac2; tac3
            · tac4; tac5
          

          would result in three sequences:

          • #[tac1, (· tac2; tac3), (· tac4; tac5)]
          • #[tac2, tac3]
          • #[tac4, tac5]

          Similarly, a declaration with multiple by blocks results in each of the blocks getting its own sequence.

          Equations
          • One or more equations did not get rendered due to their size.
          Instances For

            Run the tactic analysis passes from configs on the tactic sequences in stx, using trees to get the infotrees.

            Equations
            • One or more equations did not get rendered due to their size.
            Instances For

              A tactic analysis framework. It is aimed at allowing developers to specify refactoring patterns, which will be tested against a whole project, to report proposed changes.

              It hooks into the linting system to move through the infotree, collecting tactic syntax and state to call the passes on.

              Equations
              • One or more equations did not get rendered due to their size.
              Instances For

                Work in progress: Config building blocks #

                In this section we define ComplexConfig which is supposed to make it easier to build standard analysis rounds.

                Work in progress note: This interface does not feel intuitive yet and might be redesigned. Please do not rely on it being stable!

                The condition is returned from the .trigger function to indicate which sublists of a tactic sequence to test.

                The context field can be used to accumulate data between different invocations of .trigger.

                Instances For

                  Specifies which analysis steps to take.

                  The overall design will have three user-supplied components:

                  • trigger on a piece of syntax (which could contain multiple tactic calls);
                  • test if a suggested change is indeed an improvement;
                  • tell the user where changes can be made.
                  Instances For

                    Test the config against a sequence of tactics, using the context info and tactic info from the start of the sequence.

                    Equations
                    • One or more equations did not get rendered due to their size.
                    Instances For

                      Run the config against a sequence of tactics, using the trigger to determine which subsequences should be tested.

                      Equations
                      • One or more equations did not get rendered due to their size.
                      Instances For

                        Constructor for a Config which breaks the pass up into multiple pieces.

                        Equations
                        Instances For