Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Appendix A: Math

Most of the math that TLA+ uses is relatively simple, but not everybody has the background, so this appendix is here to help you learn what you need to know to use TLA+. This is not intended to be a rigorous or complete introduction, just enough to give you some intuition for writing TLA+ operators. You can read a more in-depth treatment of this that’s still oriented toward TLA+ in the original Specifying Systems book, which is provided in the toolbox under Help > Specifying Systems .

Most math uses a different notation than most programs. In C, you have ! for “not”, && for “and”, and || for “or”. The corresponding math notations are ¬, ∨, and ∧, none of which are part of default keyboards. That’s why in TLA+ we use ~, /, and /. For other math symbols, we generally use their LaTeX equivalents, that is, in for ∈ and otin for ∉.

Propositional Logic

Propositional Logic is how we determine statements are true or false. A proposition formula is a statement about Boolean variables we can make true or false. We usually use “T” to mean “True” and “F” to mean “False.” You might also see ⊤ (“top”) and ⊥ (“bottom”) in other places, but we won’t be using those.

As we mentioned earlier, ∧ means “and” and ∨ means “or”. So a formula like A ∧ ( B ∨ ¬C ) means “A is true AND (B is true OR C is false)”.

Two formulas are equivalent if we get the same value for all possible assignments of Boolean variables. We can visualize this with a truth table , which is a visual table of all possible assignments and results. This is a truth table for A ∧ B and A ∨ B :

A	B	A ∧ B	A ∨ B
T	T	T	T
T	F	F	T
F	T	F	T
F	F	F	F

Since their columns are different, A ∧ B ≠ A ∨ B In contrast, here’s the truth table for ¬¬A:

A	¬A	¬(¬A)
T	F	T
F	T	F

Since their columns are the same, A = ¬¬ A . When two things are equal, we can substitute one for the other in any formula. It’s pretty easy to show that A ∧ ¬ A is always false, so we can simplify ( A ∧ ¬ A ) ∨ B to just B .

In addition to the usual programming logical statements, propositional logic has ⇒ (“implies”). P ⇒ Q means “if P is true, then Q is true.” The formula P ⇒ Q , though, is only false if P is true and Q is false. If P is false, P ⇒ Q is true. Here’s a truth table:

P	Q	P ⇒ Q	¬P ∨ Q
T	T	T	T
T	F	F	F
F	T	T	T
F	F	T	T

By looking at this table, we can see that P ⇒ Q = ¬ P ∨ Q . So “P implies Q” is equivalent to saying “either P is false or Q is true.” I find it easier to mentally translate P ⇒ Q this way every time I use it. One nice thing about this form is we can combine it with ¬¬A = A to learn how to “flip” an implication:

${displaystyle egin{array}{l}PRightarrow Qkern0.5em =kern0.375em eg Pvee Q\ {}kern3.375em = eg Pvee eg eg Q\ {}kern3.375em =left( eg P ight)vee eg left( eg Q ight)\ {}kern3.5em =kern0.375em eg left( eg Q ight)vee left( eg P ight)\ {}PRightarrow Qkern0.625em = eg QRightarrow eg Pend{array}}$

Another way of saying A = B is to write A ⇔ B , which means that B is true if and only if A is true. In other words, they have the same truth value.

Finally, De Morgan’s Law is two substitutions we can make:

¬ P ∧ ¬ Q ⇔ ¬( P ∨ Q )
¬ P ∨ ¬ Q ⇔ ¬( P ∧ Q )

Try writing the truth tables for both of them to confirm that they work. De Morgan’s law is useful for simplifying conditionals.

Evaluating Propositions in TLA+

If you’ve read Chapter 2 , you know about the TLA+ expression evaluator. We can use these to check the values of propositions:

>> TRUE / FALSE

FALSE

Combined with set comprehensions, we can create a complete truth table for an expression:

>> {<<A, B, A => B>> : A, B in BOOLEAN}

{ <<FALSE, FALSE, TRUE>>,

<<FALSE, TRUE, TRUE>>,

<<TRUE, FALSE, FALSE>>,

<<TRUE, TRUE, TRUE>> }

Sets

The main collection in math is the set . A set is a collection of unique elements without order. {1, 2} is a set. {1, 1} is just the set {1}, as we do not have any duplicates in the set. <<1, 2>> is not a set, because it has an ordering. {} is a set with no elements, aka the “empty set.” {{}} is the set containing the empty set. The cardinality of a set is the number of elements in it. We write the cardinality of S as | S |. |{{}}| = 1. This corresponds to the Cardinality operator in the TLA+ FiniteSets module.

Often, we want to know if something is in a set. We write x ∈ set to say that set contains the element x, and x ∉ set to say that the set does not contain the element x. A set can contain other sets, so x ∉ {{ x }} but { x } ∈ {{ x }}.

If we have two sets, S1 and S2, we can relate them in several ways:

Two sets are equal if they have the same elements. {1} ≠ {2}, {1, 2} = {1, 2}
S1 is a subset of S2 if every element of S1 is also an element of S2. The math symbol is ⊆ ( subseteq ). {1} ⊆ {1, 2} but {1, 3} ⊈ {1, 2}.
The union of two sets is the set of elements present in either one of them. The math symbol is ∪ ( union , or cup ). {1, 2} ∪ {1, 3} = {1, 2, 3}.
The intersection of two sets is the set of elements present in both of them. The math symbol is ∩ ( intersect , or cap ). {1, 2} ∩ {1, 3} = {1}.
The set difference of two sets, written S 1 S 2, is all of the elements of S1 that are not in S2. {1, 2} {1, 3} = {2}.

There are some tautologies we can build with these. For example, ( S 1 S 2) ∩ S 2 = {}, and S 1 ⊆ S 2 ∧ S 2 ⊆ S 1 means that S 1 = S 2.

We can generalize union from two sets to a set of sets, called ⋃. ∪ { S 1, S 2, …} = S 1 ∪ S 2 ∪ …. We write ∪ as UNION in TLA+. We could do the same with intersection to get ⋂, but that’s not a core primitive of TLA+.

Finally, for every set S we have a corresponding power set 2 ^S . 2 ^S is the set of all subsets of S. We write it that way because |2 ^S | = 2 ^{|
S
|} . To see why this is the case, consider the case where S = { x , y }. We can then correlate every subset of S with a two-digit binary string:

subset	string
{ }	00
{x}	01
{y}	10
{x, y}	11

In TLA+ we write 2 ^S as SUBSET S .

So far we’ve only talked about finite sets . We can extend all of these operations to infinite sets, too. TLC can test membership of infinite sets but cannot quantify over them.

Predicate Logic

By combining propositional logic and set theory, we get predicate logic . Predicate logic lets us write formulas about the elements of sets and is the basis of almost everything we do in TLA+. Predicates extend propositons with two logical statements, called quantifiers :

∃ ( E ) means there exists . ∃ x ∈ S : P ( x ) means that there is at least one element of S where P(x) is true.
∀ ( A ) is for all . ∀ x ∈ S : P ( x ) means that for every single element of S P(x) is true.

To get a sense of how this works, let’s go through some formulas. In all these cases, Bool is the set { T, F }, Int is the set of all integers, and N at is the set {0, 1, 2, 3, . . . } (the “natural” numbers).

Natural Numbers

Historically the natural numbers started from 1, but there’s no modern consensus among mathematicians on whether or not 0 is or should be a natural number. Some math is simpler with it, and some math is simpler without it. TLA+ considers 0 a natural number, so that is what we’ll use.

∃ b ∈ Bool : b ∨ b is true, since T ∨ T is true.
- ∀ b ∈ Bool : b ∨ b is false, since F ∨ F is false.
∃ b ∈ Bool : b ∨ ¬ b is true, since T ∨ ¬ T is true.
- ∀ b ∈ Bool : b ∨ ¬ b is true, since it’s true for all (two) elements of Bool.
∃ b ∈ Bool : b ∧ ¬ b is false, since it’s false for both T and F.
- ∀ b ∈ Bool : b ∧ ¬ b is false, because it’s not true for at least one element.

You might think that ¬∃ x ∈ S : P ( x ) ⇒ ¬∀ x ∈ S : P ( x ): If there doesn’t exist any element where P is true, then P isn’t true for all elements. After all, how could something hold for all elements of S if it doesn’t hold for any elements of S?

What if S is empty? Then ¬∃ x ∈ S is vacuously true: there are no elements in S, so there aren’t any element S where P is true. But ∀ x ∈ S is also vacuously true: P(x) holds for all (zero) elements of S.

∃ x ∈ N at : x = x + x is true, because there is at least one integer that’s equal to twice itself: 0.
- ∃ x ∈ N at : x ≠ x + 0 ⇒ x = x + x looks like it’s false, but it’s actually true! This is a common pitfall with ⇒ . Remember, we can rewrite the implication as ¬(0 ≠ 0) ∨ ( x = x + x ). If we plug in x = 0, we get ¬(0 ≠ 0) ∨ (0 = 0 + 0), and both of those clauses are true!
- ∃ x ∈ N at : ( x ≠ 0) ∧ ( x = x + x ) is definitely, for-real false.
∀x, y ∈ N at : x ≥ y ∨ y ≥ x is true.
- ∀ x, y ∈ N at : x > y ∨ y > x is false, as it isn’t true if we pick x = y .
- ∀ x, y ∈ N at : x ≠ y ⇒ x > y ∨ y > x is true.

We can also nest predicates:

∃ x ∈ N at : ∀ y ∈ N at : x ≤ y is the statement “there is some smallest element of N at ” and is true (it’s 0).
∃ x ∈ N at : ∀ y ∈ N at : x < y is the statement “there is some element of N at smaller than all the elements of N at ” and is false , as 0≮0.
∃ x ∈ N at : ∀ y ∈ N at { x } : x < y is the statement “there is some element of N at smaller than all the others” and is true.
∃ x ∈ Int : ∀ y ∈ Int : x ≤ y is the statement “there is some smallest element of Int” and is false, as we can always find another smaller number.
∀ y ∈ Int : ∃ x ∈ Int : x < y is the statement “for every element of Int, there is at least one element smaller than it” and is true . The difference between this and the last example is that instead of picking one x that must hold true for every single y, we’re saying that for every single y we can pick an appropriate x. This doesn’t have to be the same x each time, though. If you give me y = − 527, and I can pick x = − 528; if you give me y = − 528, I can pick x = − 529, and so on and so forth.
∀ y ∈ N at : ∃ x ∈ N at : x < y is false, though. If you give me y = 0, I can’t pick a smaller number, because 0 is already the smallest number of N at .

Evaluating Predicates in TLA+

TLA+ cannot quantify over infinite sets. We can quantify over finite sets, though, such as BOOLEAN .

>> A A, B in BOOLEAN: (A => B) <=> (~A / B)

TRUE

>> A A, B in BOOLEAN: A <=> ~B

FALSE

>> A A in BOOLEAN: E B in BOOLEAN: A <=> ~B

TRUE

>> E B in BOOLEAN: ~(A A in BOOLEAN: A <=> ~B)

TRUE

We can use this to compare equations and check if two equations are substitutable.

>> A A, B in BOOLEAN: ~(A / B) = ~A / ~B

TRUE

Appendix B: The PT Module

This is the PT module , which contains useful support operators to help people reading Practical TLA+. Normally we would break the operators up by domain, but we lump them all here to make it easier on beginners. All operators have a description of how they work.

---- MODULE PT ----

* LOCAL means it doesn’t get included when you instantiate the module itself.

LOCAL INSTANCE FiniteSets

LOCAL INSTANCE Sequences

LOCAL INSTANCE Integers

Max(x, y) == IF x > y THEN x ELSE y

Min(x, y) == IF x < y THEN x ELSE y

(* SET STUFF *)

(* Fairly simple one, uses a set comprehension to filter subsets by their cardinality (number of elements) *)

SubsetsOfSize(set, n) == { set1 in SUBSET set : Cardinality(set1) = n}

TLA+ forbids recursive higher-order operators, but it is fine with recursive functions. Reduceset generates a recursive function over the subsets of a set, which can be used to recursively run a defined operator. This can then be used to define other recursive operators.

ReduceSet(op(_, _), set, acc) ==

LET f[s in SUBSET set] == * here’s where the magic is

IF s = {} THEN acc

ELSE LET x == CHOOSE x in s: TRUE

IN op(x, f[s {x}])

IN f[set]

(* FUNCTION STUFF *)

Gets the set of all possible values that f maps to.

essential the "opposite" of DOMAIN. Uses a set comprehension-map.

Range(f) == { f[x] : x in DOMAIN f }

Places an ARBITRARY ordering on the set. Which ordering you get is implementation-dependent but you are guaranteed to always receive the same ordering.

OrderSet(set) == CHOOSE seq in [1..Cardinality(set) -> set]: Range(seq) = set

* Get all inputs to a function that map to a given output

Matching(f, val) == {x in DOMAIN f: f[x] = val}

(* SEQUENCE STUFF *)

* TupleOf(s, 3) = s X s X s

TupleOf(set, n) == [1..n -> set]

* All sequences up to length n with all elements in set.

* Equivalent to TupleOf(set, 0) union TupleOf(set, 1) union ...

* Includes empty sequence

SeqOf(set, n) == UNION {TupleOf(set, m) : m in 0..n}

ReduceSeq(op(_, _), seq, acc) ==

ReduceSet(LAMBDA i, a: op(seq[i], a), DOMAIN seq, acc)

SelectSeq lets you filter a sequence based on a test operator. It acts on the values. SelectSeqByIndex does the exact same, except the operator tests the indices. This is useful if you need to round-robin a thing.

SelectSeqByIndex(seq, T(_)) ==

ReduceSet(LAMBDA i, selected:

IF T(i) THEN Append(selected, seq[i])

ELSE selected,

DOMAIN seq, <<>>)

* Pulls an indice of the sequence for elem.

Index(seq, elem) == CHOOSE i in 1..Len(seq): seq[i] = elem

% is 0-based, but sequences are 1-based. This means S[x % Len(S)] might be an error, as it could evaluate to S[0], which is not an element of the sequence. This is a binary operator . See [cheat sheet] to see the defineable boolean operators.

LOCAL a %% b == IF a % b = 0 THEN b ELSE a % b

SeqMod(a, b) == a %% b

=====

Appendix C: PlusCal to TLA+

In this book we used TLA+ through the intermediary of PlusCal, an algorithm syntax built on top of TLA+. While PlusCal is simple to learn and useful for a wide range of problems, not everything can be expressed in it. Rather than teach you how to write specs in TLA+, we’re going to provide an overview and intuition for how TLA+ “works.” If you want a more rigorous treatment, please refer to the book Specifying Systems , which can be accessed for free in the Toolbox under Help > Specifying Systems .

This appendix assumes you’ve read the first six chapters of the book and Appendix A. We’ll start by covering some extensions to logic, follow up with how we express properties in TLA+, and conclude with a brief discussion of when you’d want to use pure TLA+ over PlusCal.

Temporal Logic

With predicate logic, we could quantify statements: say whether something is true for all possible values, or only true for at least one value. Modal logic lets us qualify statements. □ P means that P is necessarily true. ⋄ P means that P is possibly true. What “necessarily” and “possibly” mean depends on the modal logic system you’re using. Most of them are only interesting to philosophers, but one type of modal logic, temporal logic , matters a great deal in software engineering. In a temporal logic, □ P means that P is always true, while ⋄ P means that P is sometimes true.

“Always” is unambiguous here, but there’s two common and exclusive ways people interpret “sometimes”:

1.
For every initial state, it is possible to reach a state where P is true.
2.
For every initial state, no matter what you do, you will at some point reach a state where P is true.

To see the difference between the two, consider rolling a 6-sided dice. If you roll once, is it true that ⋄( roll = 6)? Under the first interpretation , yes: it is possible that you rolled a six. Under the second interpretation, no: you could roll a 5 instead. But under both interpretations, we have ⋄( roll > 0) and ¬ ⋄( roll = 7).

TLA+ follows the second interpretation. To make it clearer we say eventually instead of sometimes . In order for these qualifiers to be useful, we need a way to talk about how our statements change. This is what makes it a temporal logic: instead of having fixed, static statements, we allow them to evolve over time.

We do this by adding a concept of a variable . You’re already familiar with this: a variable is some value that may be different at different points in time. In the context of a temporal logic, we represent “different points in time” by having a sequence of states, where the values of variables may change between states. For example, if x starts at zero, increases by one until it reaches 2, and then goes back to zero, we could represent “what happens” as the sequence (x = 0 , x = 1 , x = 2 , x = 0 ) . Here the statement ⋄( x = 2) is true, while the statement □( x = 0) is false. We call any such sequence of states a behavior .

Now that we have a means of describing behaviors and properties we want, we need a way of describing which behaviors in our system are valid , or actually can happen in our system. For example, one possible behavior is (x = 0 , x = −9, x = ” :)”, x = 0). We probably don’t want that to be valid!

In order to mark the valid behaviors, we use next-state relations , which are built on the “actions” of TLA+.

Actions

An action is a predicate between two consecutive states of a behavior. It looks and behaves exactly like any other predicate, except it also contains a prime operator (a single quote, or ’). In an action, x is the value of x in the first state, while x’ is the value of x in the next state.

This may seem confusing, so let’s give an example. Take the action Increases == x ’ > x. Increases is true for a state if, in the next state, x is greater than it was before. If the behavior is (x = 0 , x = 1 , x = 2 , x = 0 ) , Increases is true for the first and second states, but not the third state. In the first state, x = 0 and x’ = 1, so x’ > x . In the third, x = 2 and x’ = 0, so ¬ ( x’ > x ).

Another example action is

DecreaseFromAtLeastThree ==

/ x > 2

/ x’ < x

This is only true if x is greater than 2 and then decreases. In our above behavior, it is never true: while at one point x decreased, it didn’t start out greater than 2.

Why are actions important? Combined with our modal operators, actions give us a way to describe the total evolution of a system. Let’s assume our counter is supposed to be modulo-3: x starts at 0, increments by 1 each tick until it reaches 2, and then returns to 0. Every transition can be described as one of two actions:

Increment ==

/ x < 2

/ x’ = x + 1

Reset ==

/ x = 2

/ x’ = 0

Every transition is one of these actions. This means that one of these actions is always true. This means we can describe all possible behaviors as follows:

Init == (x = 0)

Next == Increment / Reset

Spec == Init / []Next

Init by itself means the starting state: x must start at zero. □ Next means that Next must be true for the entire behavior, aka either Increment is true or Reset is true. Since both of them constrain how x can change between two states, this is enough to give us a specification of our system.

Now, write the following PlusCal algorithm and translate it to TLA+:

EXTENDS Integers

(*--algorithm counter variables x = 0

begin

while TRUE do

either

await x < 2;

x := x + 1;

await x = 2;

x := 0;

end either; end while;

end algorithm; *)

Look familiar?

TLA

There are two last things we need to take care of. First of all, we require that the next-state relation must specify the new values of all variables. Between any two states, the actions that are true must cover every variable in the spec. If we forget to account for some value, say, account_total , we’re saying it doesn’t matter what account_total’ is. This means it’s a valid behavior for account_total = 1 and account_total’ = "abcdefg"! This quickly leads to nonsense, so we require that all variables are specified.

Finally, we need all of our specs to be stutter-invariant . At any point we should be able to drop in an extra state where nothing happens. Without this property, we eventually run into bizarre problems, and it becomes nearly impossible to cleanly combine two specs together. Permitting stuttering just makes the specs a whole lot cleaner. So instead of writing []Next , we write [][Next]_x . That’s equivalent to writing [](Next / UNCHANGED x) , or “either Next is true or x is unchanged.” This lets stuttering happen, giving us all the nice properties of stutter-invariance. Obviously, if our spec uses more than one variable, we’d1 have to add them too.

With that, we now have a T emporal L ogic of A ctions, or TLA . TLA+ is just TLA with some extra structure on top, such as the module system. There’s still a few small details, such as fairness, but you now have a broad overview.

You might sometimes see specs written as

THEOREM Spec => []TypeInvariant

That’s a note to the reader that if the system obeys Spec , then it will have TypeInvariant as an invariant. In practice, this doesn’t change what the model checker does; you still have to make Spec the temporal formula and add TypeInvariant as a specific invariant.

Limitations of PlusCal

PlusCal abstracts a lot of this away. For many problems, it’s perfectly adequate. However, there are some limitiations. First of all, it’s not as flexible as writing everything in TLA+. You couldn’t, for example, have an action of form (A / B) / (A / C) in PlusCal, or allow two processes to run “simultaneously.” You also can’t compose specifications with variables together in PlusCal, while it’s pretty straightforward in TLA+.

One major limitation of PlusCal is something we touched on in Chapter 9 : you can’t prove one spec is a refinement of another. In TLA+, we could instantiate the high-level spec with INSTANCE HighLevel and then check the temporal property HighLevel!Spec . That would say that every behavior of the implementation is also a valid behavior of the high level spec.

PlusCal will serve you well for a very long time. But you should know when you’re pushing against the limits.

Index

Symbol

! (namespace), see INSTANCE

' (prime)

.. (interval)

/= (not equals)

/ (and)

= VS :=

:= (assignment)

:> (map value)

See also TLC Module

<-(substitute)

for constants ( see also Constants)

for instances ( see also INSTANCE)

<< >>, see Sequences

<=> (iff)

<> (eventually)

== (define operator), see Operators

=> (implies)

@@ (function merge)

See also TLC Module

[] (always)

[] (in CASE)

[A-> B] (function set), see Functions

[a |-> b], see Structures

[key: set] (structure set)

See also Structures

[x in S |-> P], see Functions

/ (or)

A (for all)

E (there exists)

in functions

in quantifiers

initial state

set membership

otin

o (concatenate)

See also Sequences

X (sequence set)

See also Sequences

{} (set), see Sets

|| (join assignments)

See also Labels

~ (not)

~> (leads-to)

A

Action

THEOREM

Algorithms

Leftpad

precondition

verifying overflow

verifying time-complexity

assert (PlusCal)

Assert (TLA+)

ASSUME

See also Constants

Auxiliary data, see Ghost data

await

after assignments

B

Behavior

BOOLEAN

Business logic

C

call, see Procedure

CASE

CHOOSE

empty CHOOSE

See also Logic

Comments

Concurrency

concurrent algorithms

critical section

grain of atomicity, see Labels

semaphore

CONSTANT

See also Constants

Constants

constant operators

model values ( see Model values)

notation for

ordinary assignment

restricting constants

D

Data structures

verifying properties

Deadlock

define

Definition override

DOMAIN

See also Functions

E

either

possibly

Enabled

See also Action

Error trace

trace exploration

Examples

binary search

Dekker’s algorithm

knapsack problem

Leftpad

library (for books and stuff)

linked lists

MapReduce

rate limiting

reader-writer pattern

sending messages

server-client

sorting machine

Tortoise and Hare

wire

Expression evaluator

notation for

Expressions

EXTENDS

FiniteSets

integers

sequences

TLC

F

Fairness

fairness and safety

strong fairness

weak fairness

Functions

compared to operators

domain

recursive functions

sets of functions

G, H

ghost data

goto

considered helpful

I, J, K

if (PlusCal)

See also IF-THEN-ELSE (TLA+)

IF-THEN-ELSE (TLA+)

comparison with PlusCal

Imports

lookup rules

INSTANCE

namespaced instances

parameterized instances

default assignment

partial assignment

Invariants

adding to models

after translations

notation for, 50–52

L

Labels

Done

label rules

See also Action

LAMBDA

LET-IN

Liveness

See also Temporal properties

LOCAL

See also INSTANCE

Logic

De Morgan’s law

evaluating with TLA+ 201

modal logic

predicate logic

propositional logic

quantifiers

temporal logic

M

macro

Model

Model checker, see TLC

Model values

comparison

sets of model values

MODULE

name restrictions, 5

N

Natural numbers

Next-state relation

See also Action

Nondeterminism

O

Operators

anonymous operators ( see LAMBDA)

binary operators

compared to functions

higher-order operators

P, Q

pc (program counter)

See also Labels

PlusCal

--algorithm

--fair algorithm ( see also Fairness)

limitations

translating PlusCal

PrintT

Procedure

combining with fairness ( see also Fairness)

See also macro

Process

equivalent values

fair process

fair+ process

local variables ( see also variables)

process sets

ReduceSet

setup, xxii–xxiii

R

Refinement

return, see Procedure

S

Safety, see Invariants

self

See also Process, process sets

Sequences

sequence operators

sets of sequences

See also Functions

Sets

Cardinality

infinite sets

power set

set of sets ( see also SUBSET)

set transformations

UNION

skip

State constraint

See also TLC

State machine

use in refinement

Structures

set of structures

See also Functions

Stuttering

stutter-invariance

See also Fairness

SUBSET

set operators

Symmetry set

See also Model values

T

Temporal Logic of Actions

Temporal operators

<> (eventually)

limitations

[ ]<> and <>[ ]

[] (always)

~> (leads-to)

Temporal properties

considered confusing

optimization

warning against symmetry sets

Termination

formal definition ( see also pc (program counter))

See also Temporal property

TLA+ Toolbox, xxi–xxii

TLC, xvii–xviii

configuration

TLC Module

Truth table

Tuples, see Sequences

TypeInvariant

U

Unbounded model

V

Values

variables

multiple starting states

W, X, Y, Z

when, see await

while

Whitespace

with

WITH, see INSTANCE

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Index

Symbol

A

B

C

D

E

F

G, H

I, J, K

L

M

N

O

P, Q

R

S

T

U

V

W, X, Y, Z

Table of Contents for
Back Matter