# REPL This documentation is about interacting with the REPL. ## Examples After building the `repl`, it will be available in `.lake/build/bin/repl`. Execute it by either directly referring to its name, or `lake exe repl`. ``` sh repl MODULES|LEAN_OPTIONS ``` The `repl` executable must be given with a list of modules to import. By default it will import nothing, not even `Init`. It can also accept lean options of the form `--key=value` e.g. `--pp.raw=true`. Running repl with `--version` shows the version and then exits. After it emits the `ready.` signal, `repl` accepts commands as single-line JSON inputs and outputs either an `Error:` (indicating malformed command) or a JSON return value indicating the result of a command execution. The command must be given in one of two formats ``` command { ... } { "cmd": command, "payload": ... } ``` The list of available commands can be found below. An empty command aborts the REPL. Example: (~5k symbols) ``` $ repl Init env.catalog {} env.inspect {"name": "Nat.le_add_left"} ``` Example with `mathlib4` (~90k symbols, may stack overflow, see troubleshooting) ``` $ repl Mathlib.Analysis.Seminorm env.catalog {} ``` Example proving a theorem: (alternatively use `goal.start {"copyFrom": "Nat.add_comm"}`) to prime the proof ``` $ repl Init goal.start {"expr": "∀ (n m : Nat), n + m = m + n"} goal.tactic {"stateId": 0, "tactic": "intro n m"} goal.tactic {"stateId": 1, "tactic": "assumption"} goal.delete {"stateIds": [0]} stat {} goal.tactic {"stateId": 1, "tactic": "rw [Nat.add_comm]"} stat ``` where the application of `assumption` should lead to a failure. ### Project Environment To use Pantograph in a project environment, setup the `LEAN_PATH` environment variable so it contains the library path of lean libraries. The libraries must be built in advance. For example, if `mathlib4` is stored at `../lib/mathlib4`, the environment might be setup like this: ``` sh LIB="../lib" LIB_MATHLIB="$LIB/mathlib4/.lake" export LEAN_PATH="$LIB_MATHLIB:$LIB_MATHLIB/aesop/build/lib:$LIB_MATHLIB/Qq/build/lib:$LIB_MATHLIB/std/build/lib" LEAN_PATH=$LEAN_PATH repl $@ ``` The `$LEAN_PATH` executable of any project can be extracted by ``` sh lake env printenv LEAN_PATH ``` Additional modules cannot be imported after the perennial process starts, either via `env.load` or the frontend functions. The technical reason for this is when Lean cannot determine whether an imported module's initializer has run. ## Commands See `Pantograph/Protocol.lean` for a description of the parameters and return values in JSON. * `reset`: Delete all cached expressions and proof trees * `stat`: Display resource usage * `options.set { key: value, ... }`: Set one or more options. These are not Lean `CoreM` options; those have to be set via command line arguments.), for options see below. * `options.print`: Display the current set of options * `expr.echo {"expr": , "type": , ["levels": []]}`: Determine the type of an expression and format it. * `env.catalog`: Display a list of all safe Lean symbols in the current environment * `env.inspect {"name": , "value": }`: Show the type and package of a given symbol; If value flag is set, the value is printed or hidden. By default only the values of definitions are printed. * `env.save { "path": }`, `env.load { "path": }`: Save/Load the current environment to/from a file * `env.module_read { "module": }`: Reads a list of symbols from a module * `env.describe {}`: Describes the imports and modules in the current environment * `env.parse { "input": , "category": }`: Parse a bit of syntax and returns the parser's terminal position. * `goal.start {["name": ], ["expr": ], ["levels": []], ["copyFrom": ]}`: Start a new proof from a given expression or symbol * `goal.tactic {"stateId": , ["goalId": ], ["autoResume": ], ...}`: Execute a tactic string on a given goal site. The tactic is supplied as additional key-value pairs in one of the following formats: - `{ "tactic": }`: Executes a tactic or a sequence of tactics in the current mode. - `{ "mode": }`: Enter a different tactic mode. The permitted values are `tactic` (default), `conv`, `calc`. In case of `calc`, each step must be of the form `lhs op rhs`. An `lhs` of `_` indicates that it should be set to the previous `rhs`. - `{ "expr": }`: Assign the given proof term to the current goal - `{ "have": , "binderName": }`: Execute `have` and creates a branch goal - `{ "let": , "binderName": }`: Execute `let` and creates a branch goal - `{ "draft": }`: Draft an expression with `sorry`s, turning them into goals. Coupling is not allowed. If the `goals` field does not exist, the tactic execution has failed. Read `messages` to find the reason. * `goal.continue {"stateId": , ["branch": ], ["goals": ]}`: Execute continuation/resumption - `{ "branch": }`: Continue on branch state. The current state must have no goals. - `{ "goals": }`: Resume the given goals * `goal.subsume {"stateId": , "goal": , "candidates": , ["srcStateId": ]}`: determine if any goal in `candidates` (coming from either the provided state id or `srcStateId`) subsumes `goal`. It returns the *subsumptor* (goal providing the solution) and a new state id if the subsumption is not a cycle, in which case the *subsumend* `goal` is erased. * `goal.remove {"stateIds": []}"`: Drop the goal states specified in the list * `goal.print {"stateId": }"`: Print a goal state * `goal.save { "id": , "path": }`, `goal.load { "path": }`: Save/Load a goal state to/from a file. The environment is not carried with the state. The user is responsible to ensure the sender/receiver instances share the same environment. * `frontend.process { ["fileName": ,] ["file": ], readHeader: , inheritEnv: , invocations: , newConstants: }`: Executes the Lean frontend on a file, collecting the tactic invocations (`"invocations": output-path`), or new constants (`newConstants`) * `frontend.distil { "file": , ["binderName": ], "ignoreValues": bool }`: Extract condensed search targets from a file, where coupled search targets will be condensed into one. Set `binderName` to override the binder name to e.g. `f`. Set `ignoreValues` to false to incorporate existing solutions. Note that `example`s are not search targets! * `frontend.track { "src": , "dst": }`: Check if one file conforms to another. The declarations in `src` could have `sorry`s and the declarations in `dst` would fill them. * [Experimental] `frontend.refactor { "file": , "coreOptions": [["="]] }`: Group dependent `sorry`s into one single `sorry`. Currently only flat dependencies are supported (i.e. an object with a list of properties). ## Options The full list of options can be found in `Pantograph/Protocol.lean`. Particularly: - `automaticMode` (default on): Goals will not become dormant when this is turned on. By default it is turned on, with all goals automatically resuming. This makes Pantograph act like a gym, with no resumption necessary to manage your goals. - `timeout` (default 0): Set `timeout` to a non-zero number to specify timeout (milliseconds) for all `CoreM` and frontend operations. ## Errors When an error pertaining to the execution of a command happens, the returning JSON structure is ``` json { "error": "type", "desc": "description" } ``` Common error forms: * `command`: Indicates malformed command structure which results from either invalid command or a malformed JSON structure that cannot be fed to an individual command. * `index`: Indicates an invariant maintained by the output of one command and input of another is broken. For example, attempting to query a symbol not existing in the library or indexing into a non-existent proof state. * `parse`: Indicates parsing errors * `elab`: Indicates elaboration errors * `frontend`: Indicates whole-file parsing and elaboration errors * `io`: Generic IO error * `command`: The command's argument is malformed ## Troubleshooting If lean encounters stack overflow problems when printing catalog, execute this before running lean: ```sh ulimit -s unlimited ```