TLA+ Toolbox should have a REPL

From my own experiences with Alloy, a REPL is really nice. It makes learning the language easier, as you don’t have to add anything to your core spec to explore. It makes it possible to query information about a given trace to learn more about it. Andrew Helwer cites a REPL as a key advantage of Runway.

This has been discussed before. Here were some alternatives raised:

• Using “Evaluate Constant Expression”: This only works on the initial state of a behavior. It takes time to run. It does not (easily) allow defining new operators without using let, which is awkward. No history of expressions.
• Using multiple ASSUME: Limitations covered by Chris Newcombe here.
• Using Error Traces: Evaluated at every step of the trace, cluttery, specifically only for debugging while specs fail.

Lamport asked for specific scenarios for where a REPL would be useful. Here are some I’ve run into:

• I’m not sure a particular part of the language works. Can I do CHOOSE x \in A, b \in Y? With a REPL, I can test that quickly and see it does not work.
• I’m not sure what a particular logical expression does. Is \E foo \in F: \A bar \in B what I want? With a REPL, I can try a few different logical expressions and see what I want.
• A spec is failing and I don’t understand why. I could use Error Traces, but I don’t know what I’m looking for yet. I want be able to take the state one step before the error and try several different expressions to see if I can figure out what it is I don’t know.
• I want to use some debugging operators that shouldn’t be part of the spec.

I think all of these could be resolved with a REPL that would allow the following:

1. Load at the initial state of a spec, or a given state of a failing behavior
2. Definition of new operators and actions
3. Evaluation of arbitrary expressions, including with the new operators and actions
4. Fast (May be untenable if requires heavy TLC refactors)

To make this simpler, the REPL should not be able to change the trace. If x = 1 and x' = 2, x' = 3 would be FALSE. This means that you cannot use the REPL to test a change to a spec. You can only use it to explore information about an existing spec.

[will62794]

I was aware of this Github issue before I created my Python based REPL. I figured that my tool would contain a subset of the functionality that would eventually be desired in a full-fledged TLA+ REPL (one that had more explicit support from TLC and closer integration with the Toolbox). I wanted something to use before this Github issue was completed, so I worked around the existing limitations of TLC. I imagine my tool could serve as a reasonable testing ground for ideas/features that we might want to add in to a full REPL. It could also let people play around with it and see if they find such a tool useful, even if it is a bit primitive.

[lemmy]

The REPL could be optimized by writing a dedicated SpecProcessor that does not eagerly evaluate expressions. The current implementation of the REPL evaluates the expressions twice.