Tag(sp22)
Formally, the temporal operators Forge provides correspond to a language called Linear Temporal Logic (or LTL). It's temporal because it has temporal operators like always
and eventually
, and it's linear because it's interpreted over (infinite) linear traces.
LTL is commonly used in industry. And even where it isn't used directly, many other temporal specification languages are either related to LTL (e.g., branching-time logics like CTL) or inspired by it (e.g., TLA+ and other more recent languages). There are a lot of industrial model-checking tools out there, using a lot of different languages, but learning LTL will help you build intuition for nearly all of them.
(And on the research side of things, there's been work right here at Brown to use LTL for specifying robot behaviors! For example, this paper.)
Recall that time is implicit in temporal mode, and that temporal mode only ever finds lasso traces. When you write a constraint in temporal mode, it's true with respect to an instance (which is always a lasso traces) and a time index into that trace. Thus the init
predicate may be true, or not true, depending on which state you're looking at.
Evaluation always starts at the first state. This corresponds to the top-level run
command or test
. I didn't say "the initial state", because if we've got a predicate that encodes "initial state", it won't be enforced unless we've told Forge to do so. This is why, usually, you'll start by putting:
(or whatever your initial-state predicate is) in your top-level run
.
As soon as temporal operators become involved, however, the "evaluate in the first state" rule starts to fail.
You can refer to the next state (relative to the current one, whatever it is) by using the next_state
operator. If I wanted to say that the second and third states would also be acceptable as initial states, I'd write:
in the top-level run
block. It's rare you'd do something like this in practice, but it's a good first demonstration of the operator.
next_state
?The keyword is, admittedly, a little verbose. But it was the best of the various candidates at hand:
X
, which is not very descriptive.after
, but this can lead to some misconceptions since A after B
might be misinterpreted as a binary operator, and Forge and Alloy both have implicit and
via newlines.afterward
suggested, but that risks confusion with always
or eventually
.What does it mean for something to always
be true, or to eventually
hold? These terms effectively quantify over time: if something is always
true, it's true at all time indexes (starting now). If something is eventually
true, it's true at some time index (possibly now).
So if we wanted to say that every state in the trace transitions to its successor in accordance with our move
predicate, we'd say:
Just like you can nest all
and some
, you can nest always
and eventually
. We'll need to do this to express properties like non-starvation. In fact, let's think about how to express non-starvation now!
We had informally case non-starvation as something like "once a process becomes interested, it eventually gets access". How would you write this using temporal operators, assuming that interested
and access
were predicates describing the process becoming interested and getting access respectively?
Clearly we need to add some sort of temporal operator that prevents the above issue. Here's a possible candidate: (eventually interested) => (eventually access)
.
How about eventually (interested => (eventually access))
?
Why? Think about how an implication is satisfied. It can be satisfied if the right-hand side is true, but also if the left-hand side is false–-in the case where no obligation needs to be incurred! So the implication above evaluates to true in any state where the process isn't interested. And using eventually
means any single such state works…
It seems like we need a different temporal operator…
We'll say: always {interested => eventually access}
. Now, no matter what time it is, if the process is interested, it has to eventually get access.
This sort of always
-eventually
pattern is good for (contingent) "infinitely often" properties, which is exactly what non-starvation is.
I'm going to ask you to play the role of Forge. I've listed some temporal constraints below, and would like you to come up with some instances (lasso traces) that satisfy them. Don't use Forge unless you've already tried, and are stumped.
For all examples, you may come up with your own shape of the world. That is, you might pick a University (where a state is a semester, with courses offered and taken) or your experience waiting for an elevator in the CIT, or anything else from your life! I'll use X
, Y
and Z
to denote arbitrary facts that might be true, or not true–-your job is to plug in specifics, and then find a satisfying trace!
I'll use a lot of parentheses, to avoid confusion about operator precedence…
eventually (always (X or Y))
I am probably abstracting out some important details here, like the heat-death of the universe. But that's not really the point. The point is that alternation between X
and Y
is allowed–-it's always either one or the other, or possibly even both.
On Monday, we'll talk more about temporal modeling in Forge.