> A model checker doesn't imply anything about the kind of the formal specification used.
That is true; I was just contrasting the way TFA explained specifications as being definitions of groups of acceptable execution traces (perhaps checked using a model checker) with Dijkstra’s approach of characterizing the acceptable behavior without simulating any executions.
Both are of course valid approaches to demonstrate the correctness of a specification.
> I was just contrasting the way TFA explained specifications as being definitions of groups of acceptable execution traces (perhaps checked using a model checker) with Dijkstra’s approach of characterizing the acceptable behavior without simulating any executions.
I think that's a misunderstanding, as TLA+ doesn't require simulating anything (even the model checker doesn't work like that; it can check a formula that corresponds to an uncountable infinity of behaviours, each of them infinite, in a second [1]), and Dijkstra's approach is separate from the logical semantics.
It is true that a TLA formula denotes a set (really, a class) of something called "behaviours" (which could be interpreted as execution traces when a formula is interpreted to describe a program) just as the statement x > 3 denotes the set of all integers greater than 3 (in a logic over the integers), but in neither case is enumerating or "simulating" anything required, either in principle or in practice. It's just simple logical semantics, and Dijkstra's approach is easily expressed in a logic with such simple semantics.
In fact, TLA serves as a generalisation of Dijkstra's approach, as that is lacking when dealing with concurrency. While in sequential programs it is easy to specify invariants as pre/post conditions, it is hard to do that in concurrent/distributed programs.
[1]: You can ask the TLC model checker to simulate behaviours if you want (it can be useful sometimes), but checking mode, not simulation mode, is the default. Obviously, in simulation mode TLC doesn't work as a model checker. Technically speaking, every TLA formula denotes an uncountable infinity of behaviours of infinite lengths, where between any two states in the behaviour there is an infinite number of steps (it is in this regard that TLA is different from other temporal logics like LTL), and each state in every behaviour is an assignment to an infinite number of variables (in fact, that uncountable infinity is so large that it doesn't even correspond to a set in the set theory sense but to something called a class). The large infinities are what makes TLA so suitable for expressing abstractions and refinement and interactions between components.
This may sound strange, but it's actually how most simple logics work. When I said before that `x > 3` in a logic over the integers denotes the set of integers greater than 3, I wasn't entirely precise. What it really denotes is: "x is in the set of integers greater than three and any other imaginable variable could be any integer".
I was referring to way the Python REPL examples/tree diagrams and sections on execution histories were used to explain things in the article, not to TLA+. I was contrasting how the author explained specifications versus how someone like Dijkstra would, not anything about TLA+. I don’t know enough about TLA+ to say anything interesting, but I appreciate your explanations of its approach!
That is true; I was just contrasting the way TFA explained specifications as being definitions of groups of acceptable execution traces (perhaps checked using a model checker) with Dijkstra’s approach of characterizing the acceptable behavior without simulating any executions.
Both are of course valid approaches to demonstrate the correctness of a specification.