The document discusses different ways of thinking about programs, including as mathematical functions and as sequences of states. It argues that the most useful models for understanding programs are functions, which specify what a program does but not how, and sequences of states, which represent a program execution as a behavior consisting of a sequence of states. Some limitations of the functional model are that it does not capture how a program works or handle programs with non-terminating or stateful behaviors.

1. Thinking For Programmers
Leslie Lamport
Microsoft Research
0

2. Why Think?
It helps us do most things:
Hunting a sabre-toothed tiger.
Building a house.
Writing a program.
0

3. Why Think?
It helps us do most things:
Hunting a sabre-toothed tiger.
Building a house.
Writing a program.
0

4. Why Think?
It helps us do most things:
Hunting a sabre-toothed tiger.
Building a house.
Writing a program.
0

5. Why Think?
It helps us do most things:
Hunting a sabre-toothed tiger.
Building a house.
Writing a program.
0

6. Why Think?
It helps us do most things:
Hunting a sabre-toothed tiger.
Building a house.
Writing a program.
0

7. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

8. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

9. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

10. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

11. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

12. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

13. When to Think
Hunting a sabre-toothed tiger.
Before leaving the cave.
Building a house.
Before beginning construction.
Writing a program.
Before writing any code.
1

14. How to Think
“Writing is nature’s way of letting you know how
sloppy your thinking is.”
Guindon
To think, you have to write.
If you’re thinking without writing, you only think you’re thinking.
1

15. How to Think
“Writing is nature’s way of letting you know how
sloppy your thinking is.”
Guindon
To think, you have to write.
If you’re thinking without writing, you only think you’re thinking.
1

16. How to Think
“Writing is nature’s way of letting you know how
sloppy your thinking is.”
Guindon
To think, you have to write.
If you’re thinking without writing, you only think you’re thinking.
1

17. How to Think
“Writing is nature’s way of letting you know how
sloppy your thinking is.”
Guindon
To think, you have to write.
If you’re thinking without writing, you only think you’re thinking.
1

18. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

19. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

20. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

21. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

22. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

23. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a
2

24. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a blueprint
2

25. What to Write
Hunting a sabre-toothed tiger.
Writing not invented, dangerous activity.
Building a house.
Draw blueprints.
Writing a program.
Write a blueprint specification.
2

26. Specifications
Don’t Panic!
3

27. Specifications
Don’t Panic!
3

28. Specifications
Don’t Panic!
This is a blueprint:
3

29. Specifications
Don’t Panic!
This is also a blueprint:
3

30. A spectrum of blueprints
3

31. A spectrum of blueprints
3

32. A spectrum of blueprints
Very Detailed
3

33. A spectrum of blueprints
Very Detailed
3

34. A spectrum of blueprints
Rough Sketch Very Detailed
3

35. A spectrum of blueprints
Rough Sketch Very Detailed
3

36. A spectrum of blueprints
Rough Sketch Ordinary Very Detailed
3

37. A spectrum of specifications
5

38. A spectrum of specifications
Formal
5

39. A spectrum of specifications
Prose Formal
5

40. A spectrum of specifications
Prose Mathematical Prose Formal
5

41. A spectrum of specifications
Prose
Most code is really simple.
It can be specified with a couple of lines of prose.
5

42. A spectrum of specifications
Prose
Most code is really simple.
It can be specified with a couple of lines of prose.
5

43. A spectrum of specifications
Mathematical Prose
Some code is subtle.
It requires more thought.
5

44. A spectrum of specifications
Mathematical Prose
Some code is subtle.
It requires more thought.
5

45. A spectrum of specifications
Formal
Some code is complex or very subtle or critical.
5

46. A spectrum of specifications
Formal
Some code is complex or very subtle or critical.
Especially in concurrent/distributed systems.
5

47. A spectrum of specifications
Formal
Some code is complex or very subtle or critical.
We should use tools to check it.
5

48. How to Write a Spec
Writing requires thinking.
5

49. How to Write a Spec
Writing requires thinking.
5

50. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

51. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

52. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

53. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

54. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

55. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

56. How to Think About Programs
Like a Scientist
A very successful way of thinking.
Science makes mathematical models of reality.
Astronomy:
Reality: planets have mountains, oceans, tides, weather, . . .
Model: planet a point mass with position & momentum.
6

57. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

58. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

59. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

60. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

61. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

62. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

63. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

64. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

65. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

66. Computer Science
Reality: Digital systems
a processor chip
a game console
a computer executing a program
...
Models: Turing machines
Partially ordered sets of events
...
6

67. The Two Most Useful Models
Functions
Sequences of States
7

68. The Two Most Useful Models
Functions
Sequences of States
7

69. The Two Most Useful Models
Functions
Sequences of States
7

70. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
8

71. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
8

72. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
8

73. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Not in TLA+
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
8

74. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
8

75. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
square(2) = 4
8

76. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
Domain of square is f0; 1; 2; 3; : : :g a.k.a. Nat
8

77. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
To define a function, specify:
Domain of square = Nat
square(x ) = x 2 for all x in its domain.
8

78. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
To define a function, specify:
Domain of square = Nat
square(x ) = x 2 for all x in its domain.
8

79. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
Functions in math6= functions in programming languages.
8

80. Functions
Model a program as a function mapping input(s) to output(s).
In math, a function is a set of ordered pairs.
Example: the square function on natural numbers
fh0; 0i; h1; 1i; h2; 4i; h3; 9i; : : : g
Functions in math6= functions in programming languages.
Math is much simpler.
8

81. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

82. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

83. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

84. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

85. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

86. Limitations of the Function Model
Specifies what a program does, but not how.
– Quicksort and bubble sort compute the same function.
Some programs don’t just map inputs to outputs.
– Some programs run “forever”.
– Operating systems
9

87. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

88. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

89. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

90. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

91. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

92. The Standard Behavioral Model
A program execution is represented by a behavior.
A behavior is a sequence of states.
A state is an assignment of values to variables.
A program is modeled by a set of behaviors:
the behaviors representing possible executions.
9

93. An Example: Euclid’s Algorithm
Computes GCD of M and N by:
– Initialize x to M and y to N.
– Keep subtracting the smaller of x and y from the larger.
– Stop when x = y.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

94. An Example: Euclid’s Algorithm
An algorithm is an abstract program.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

95. An Example: Euclid’s Algorithm
Computes GCD of M and N by:
– Initialize x to M and y to N.
– Keep subtracting the smaller of x and y from the larger.
– Stop when x = y.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

96. An Example: Euclid’s Algorithm
Computes GCD of M and N by:
– Initialize x to M and y to N.
– Keep subtracting the smaller of x and y from the larger.
– Stop when x = y.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

97. An Example: Euclid’s Algorithm
Computes GCD of M and N by:
– Initialize x to M and y to N.
– Keep subtracting the smaller of x and y from the larger.
– Stop when x = y.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

98. An Example: Euclid’s Algorithm
Computes GCD of M and N by:
– Initialize x to M and y to N.
– Keep subtracting the smaller of x and y from the larger.
– Stop when x = y.
For M = 12 and N = 18, one behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
10

99. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
11

100. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
11

101. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
11

102. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
11

103. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
For infinite behaviors, also need fairness.
11

104. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
For infinite behaviors, also need fairness.
I will ignore this.
11

105. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
What language should we use?
We can use math.
11

106. How to Describe a Set of Behaviors
With two things:
– The set of possible initial states.
– A next-state relation,
describing all possible successor states of any state.
What language should we use?
We can use math.
11

107. The Set of Initial States
Described by a formula.
For Euclid’s Algorithm: (x = M) ^ (y = N)
Only possible initial state: [x = M; y = N]
12

108. The Set of Initial States
Described by a formula.
For Euclid’s Algorithm: (x = M) ^ (y = N)
Only possible initial state: [x = M; y = N]
12

109. The Set of Initial States
Described by a formula.
For Euclid’s Algorithm: (x = M) ^ (y = N)
Only possible initial state: [x = M; y = N]
12

110. The Set of Initial States
Described by a formula.
For Euclid’s Algorithm: (x = M) ^ (y = N)
Only possible initial state: [x = M; y = N]
12

111. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x > y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

112. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

113. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

114. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

115. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

116. The Next-State Relation
Described by a formula.
Unprimed variables for current state,
Primed variables for next state.
For Euclid’s Algorithm: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
13

117. For Euclid’s Algorithm
Take M = 12, N = 18
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

118. For Euclid’s Algorithm
Take M = 12, N = 18
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

119. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

120. For Euclid’s Algorithm
Init: (x = 12) ^ (y = 18)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

121. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

122. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( 12 18
^ x 0 = 12 18
^ y0 = 18 )
_ ( 18 12
^ y0 = 18 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

123. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next : ( 12 18 FALSE
^ x 0 = 12 18
^ y0 = 18 )
_ ( 18 12 TRUE
^ y0 = 18 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

124. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
^ x 0 = 12 18
HH HH HH H
Next: ( 12 18
FALSE
^ y0 = 18 )
_ ( 18 12
^ y0 = 18 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

125. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
^ x 0 = 12 18
HH HH HH H
Next: ( 12 18
FALSE
^ y0 = 18 )
_ ( 18 12
^ y0 = 18 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

126. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
^ x 0 = 12 18
HH HH HH H
Next: ( 12 18
FALSE
^ y0 = 18 )
_ ( 18 12
^ y0 = 18 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

127. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

128. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( 12 6
^ x 0 = 12 6
^ y0 = 6 )
_ ( 6 12
^ y0 = 6 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

129. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next : ( 12 6 TRUE
^ x 0 = 12 6
^ y0 = 6 )
_ ( 6 12 FALSE
^ y0 = 6 12
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

130. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( 12 6
^ x 0 = 12 6
^ y0 = 6 )
HH HH HH H
^ y0 = 6 12
_ ( 6 12
FALSE
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

131. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( 12 6
^ x 0 = 12 6
^ y0 = 6 )
HH HH HH H
^ y0 = 6 12
_ ( 6 12
FALSE
^ x 0 = 12 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

132. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

133. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
Next : ( 6 6 FALSE
^ x 0 = 6 6
^ y0 = 6 )
_ ( 6 6 FALSE
^ y0 = 6 6
^ x 0 = 6 )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

134. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
^ x 0 = 6 6
HH HH HH H
Next: ( 6 6
FALSE
^ y0 = 6 )
^ y0 = 6 6
HH HH HH H
_ ( 6 6
FALSE
^ x 0 = )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

135. For Euclid’s Algorithm
Init: (x = M) ^ (y = N)
^ x 0 = 6 6
HH HH HH H
Next: ( 6 6
FALSE
^ y0 = 6 )
^ y0 = 6 6
HH HH HH H
_ ( 6 6
FALSE
NO NEXT STATE
^ x 0 = )
Behavior:
[x = 12; y = 18] ! [x = 12; y = 6] ! [x = 6; y = 6]
16

136. What About Formal Specs?
Need them only to apply tools.
Require a formal language.
16

137. What About Formal Specs?
Need them only to apply tools.
Require a formal language.
16

138. What About Formal Specs?
Need them only to apply tools.
Require a formal language.
16

139. The Language: TLA+
17

140. The Language: TLA+
This
Init: (x = M) ^ (y = N)
Next: ( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
17

141. The Language: TLA+
becomes
MODULE Euclid
EXTENDS Integers
Init =
(x = M) ^ (y = N)
Next =
( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
17

142. The Language: TLA+
plus some boilerplate.
MODULE Euclid
EXTENDS Integers
Init =
(x = M) ^ (y = N)
Next =
( x y
^ x 0 = x y
^ y0 = y )
_ ( y x
^ y0 = y x
^ x 0 = x )
17

143. The Language: TLA+
You type
--------------- MODULE Euclid ----------------
EXTENDS Integers
Init == (x = M) / (y = N)
Next == ( x y
/ x’ = x - y
/ y’ = y )
/ ( y x
/ y’ = y - x
/ x’ = x )
===============================================
17

144. You can model check TLA+ specs.
You can write formal correctness proofs
and check them mechanically.
But math works only for toy examples.
To model real systems, you need a real language
with types, procedures, objects, etc.
Wrong
18

145. You can model check TLA+ specs.
You can write formal correctness proofs
and check them mechanically.
But math works only for toy examples.
To model real systems, you need a real language
with types, procedures, objects, etc.
Wrong
18

146. You can model check TLA+ specs.
You can write formal correctness proofs
and check them mechanically.
But math works only for toy examples.
To model real systems, you need a real language
with types, procedures, objects, etc.
Wrong
18

147. You can model check TLA+ specs.
You can write formal correctness proofs
and check them mechanically.
But math works only for toy examples.
To model real systems, you need a real language
with types, procedures, objects, etc.
Wrong
18

148. You can model check TLA+ specs.
You can write formal correctness proofs
and check them mechanically.
PP
But math PP PP works PP only for toy examples.
PP PP To model real systems, you PP need PP a real language
with types, procedures, objects, etc.
PP PP PP Wrong
18

149. TLA+ Use at Amazon (incomplete list)
19

150. Design Bugs
Not just simple coding bugs
Serious, often impossible to find by testing.
Ask Chris Newcombe about TLA+.
I’ll talk about informal specs, starting with an example.
19

151. Design Bugs
Not just simple coding bugs
Serious, often impossible to find by testing.
Ask Chris Newcombe about TLA+.
I’ll talk about informal specs, starting with an example.
19

152. Design Bugs
Not just simple coding bugs
Serious, often impossible to find by testing.
Ask Chris Newcombe about TLA+.
I’ll talk about informal specs, starting with an example.
19

153. Design Bugs
Not just simple coding bugs
Serious, often impossible to find by testing.
Ask Chris Newcombe about TLA+.
I’ll talk about informal specs, starting with an example.
19

154. Design Bugs
Not just simple coding bugs
Serious, often impossible to find by testing.
Ask Chris Newcombe about TLA+.
I’ll talk about informal specs, starting with an example.
19

155. TLATEX — the TLA+ pretty-printer
19

156. TLATEX — the TLA+ pretty-printer
The input:
Foo = / a = b
/ ccc = d
20

157. TLATEX — the TLA+ pretty-printer
The input:
Foo = / a = b
/ ccc = d
The naive output:
Foo ) ^ a = b
^ ccc = d
20

158. TLATEX — the TLA+ pretty-printer
The input:
Foo = / a = b
/ ccc = d
The naive output:
Foo ) ^ a = b
^ ccc = d
The user probably wanted these aligned.
20

159. TLATEX — the TLA+ pretty-printer
The input:
Foo = / a = b
/ ccc = d
The right output:
Foo ) ^ a = b
^ ccc = d
The user probably wanted these aligned.
20

160. TLATEX — the TLA+ pretty-printer
The input:
/ aaa + bb = c
/ iii = jj * k
21

161. TLATEX — the TLA+ pretty-printer
The input:
/ aaa + bb = c
/ iii = jj * k
The naive output:
^ aaa + bb = c
^ iii = jj k
21

162. TLATEX — the TLA+ pretty-printer
The input:
/ aaa + bb = c
/ iii = jj * k
The naive output:
^ aaa + bb = c
^ iii = jj k
The user probably didn’t wanted these aligned.
21

163. TLATEX — the TLA+ pretty-printer
The input:
/ aaa + bb = c
/ iii = jj * k
The right output:
^ aaa + bb = c
^ iii = jj k
The user probably didn’t wanted these aligned.
21

164. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

165. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

166. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

167. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

168. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

169. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

170. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

171. There is no precise definition of correct alignment.
We can’t specify mathematically what the user wants.
If we can’t specify correctness, specification is useless.
Wrong.
Not knowing what a program should do means
we have to think even harder.
Which means that a spec is even more important.
What did I do?
Let’s look at my Java code.
21

172. /***************************************************************************
* CLASS FindAlignments *
* *
* Contains the one public method *
* *
* public static void FindAlignments(Token[][] spec) *
* *
* that sets the aboveAlign, belowAlign, and isAlignmentPoint fields for *
* all tokens in the tokenized spec spec--except for NULL and MULTI *
* comment tokens, for which the aboveAlign field is set by *
* CommentToken.processComments. (This method should be called after *
* CommentToken.processComments.) *
* *
* There are six kinds of alignments, illustrated by the following *
* example: *
* *
* Alignment Type Tokens so aligned *
* -------------- ----------------- *
* FirstNonLeftComment foo, x, + , / , y/comment r, u/comment k *
* LeftComment comments j *
* CommentInner comments p *
* InfixInner ==, = , *
* AfterInfixInner m, c, *
* InfixArg a, z/z, y/z *
* *
* foo == LET x == / a = m * n c *
* | | | | | | | | | | *
* (* j *) | | | | / a = m / q c (* p *) *
* | | | | | | *
* (* j *) | | x == z | *
* | | | | *
* | | + z * p *
* | | | | | *
* 22

173. /***************************************************************************
* CLASS FindAlignments *
* *
* Contains the one public method *
* *
* public static void FindAlignments(Token[][] spec) *
* *
* that sets the aboveAlign, belowAlign, and isAlignmentPoint fields for *
* all tokens in the tokenized spec spec--except for NULL and MULTI *
* comment tokens, for which the aboveAlign field is set by *
* CommentToken.processComments. (This method should be called after *
* CommentToken.processComments.) *
* *
* There are six kinds of alignments, illustrated by the following *
* example: *
* *
* Alignment Type Tokens so aligned *
* -------------- ----------------- *
* FirstNonLeftComment foo, x, + , / , y/comment r, u/comment k *
* LeftComment comments j *
* CommentInner comments p *
* InfixInner ==, = , *
* AfterInfixInner m, c, *
* InfixArg a, z/z, y/z *
* *
* foo == LET x == / a = m * n c *
* | | | | | | | | | | *
* (* j *) | | | | / a = m / q c (* p *) *
* | | | | | | *
* (* j *) | | x == z | *
* | | | | *
* | | + z * p *
* | | | | | *
* 22

174. /***************************************************************************
* CLASS FindAlignments *
* *
* Contains the one public method *
* *
* public static void FindAlignments(Token[][] spec) *
* *
* that sets the aboveAlign, belowAlign, and isAlignmentPoint fields for *
* all tokens in the tokenized spec spec--except for NULL and MULTI *
* comment tokens, for which the aboveAlign field is set by *
* CommentToken.processComments. (This method should be called after *
* CommentToken.processComments.) *
* *
* There are six kinds of alignments, illustrated by the following *
* example: *
* *
* Alignment Type Tokens so aligned *
* -------------- ----------------- *
* FirstNonLeftComment foo, x, + , / , y/comment r, u/comment k *
* LeftComment comments j *
* CommentInner comments p *
* InfixInner ==, = , *
* AfterInfixInner m, c, *
* InfixArg a, z/z, y/z *
* *
* foo == LET x == / a = m * n c *
* | | | | | | | | | | *
* (* j *) | | | | / a = m / q c (* p *) *
* | | | | | | *
* (* j *) | | x == z | *
* | | | | *
* | | + z * p *
* | | | | | *
*
* There are six kinds of alignments, *
* illustrated by the following example: *
22

175. /***************************************************************************
* CLASS FindAlignments *
* *
* Contains the one public method *
* *
* public static void FindAlignments(Token[][] spec) *
* *
* that sets the aboveAlign, belowAlign, and isAlignmentPoint fields for *
* all tokens in the tokenized spec spec--except for NULL and MULTI *
* comment tokens, for which the aboveAlign field is set by *
* CommentToken.processComments. (This method should be called after *
* CommentToken.processComments.) *
* *
* There are six kinds of alignments, illustrated by the following *
* example: *
* *
* Alignment Type Tokens so aligned *
* -------------- ----------------- *
* FirstNonLeftComment foo, x, + , / , y/comment r, u/comment k *
* LeftComment comments j *
* CommentInner comments p *
* InfixInner ==, = , *
* AfterInfixInner m, c, *
* InfixArg a, z/z, y/z *
* *
* foo == LET x == / a = m * n c *
* | | | | | | | | | | *
* (* j *) | | | | / a = m / q c (* p *) *
* | | | | | | *
* (* j *) | | x == z | *
* | | | | *
* | | + z * p *
* | | | | | *
* 22

176. * | | | | (* p *) *
* | | | | | *
* | | + y (* p *) *
* | | | *
* | | * r *
* | | *
* foo == *
* | *
* (* k *) *
* | *
* u + v *
* *
* For InfixInner and CommentInner alignment, a token’s belowAlign *
* field points to the token directly below it with which it is *
* aligned. *
* *
* For all alignment types, if a token t1 is aligned with a token *
* t2 above it, then t1.aboveAlign points to: *
* *
* IF t2 has no aboveAlign pointer THEN t2 *
* ELSE t2.abovealign. *
* *
* Thus, in the example above, the aboveAlign pointer for all the p *
* comments point to the first p comment. *
* *
* To define the types of alignment, we use the following definitions: *
* *
* - A LEFT-COMMENT is a comment that is the first token on its line but *
* not the last token on its line. (The comments (* j *) in the *
* example are left-comments.) For all the types of alignment except *
* CommentInner, left-comments are treated as if they didn’t exist. *
* *
* - A RIGHT-COMMENT is a comment that is the last token on its line. * 22

177. * Any comment other than a left-comment or a right-comment is treated *
* like any other non-built-in token. We also define: *
* *
* - The COVERING TOKEN of a token t is the right-most token ct that *
* covers t on the last line (one with biggest line number) containing *
* a token that covers t, where a token t1 COVERS a token t2 if t1 *
* lies on an earlier line than t2 and t1.column leq t2.column. *
* However, if there is a DASH between ct and t, or *
* on the same line as ct, then t has no covering token. *
* (This definition has two versions, depending on whether or not *
* left-comments are ignored.) *
* *
* - The BLOCKING TOKEN of a token t is the left-most token s with *
* s.column geq t.column on the last line before t’s line containing *
* such a non-left-comment token s. *
* *
* Here are the descriptions of the different types of alignment. *
* *
* CommentInner: *
* Token t at position pos is CommentInner above-aligned with its *
* blocking token bt at position bpos iff: *
* / t is a right-comment *
* / bt is a right-comment *
* / t.column = bt.column *
* / / bt is not above-aligned with anything *
* / bt is CommentInner aligned with a token above it *
* *
* FirstNonLeftComment *
* If t is the first token on a line that is not a left-comment, and is *
* not a right-comment that is CommentInner aligned with a token above *
* it, then t is FirstNonLeftComment aligned with its covering token. *
* *
22

178. * Any comment other than a left-comment or a right-comment is treated *
* like any other non-built-in token. We also define: *
* *
* - The COVERING TOKEN of a token t is the right-most token ct that *
* covers t on the last line (one with biggest line number) containing *
* a token that covers t, where a token t1 COVERS a token t2 if t1 *
* lies on an earlier line than t2 and t1.column leq t2.column. *
* However, if there is a DASH between ct and t, or *
* on the same line as ct, then t has no covering token. *
* (This definition has two versions, depending on whether or not *
* left-comments are ignored.) *
* *
* - The BLOCKING TOKEN of a token t is the left-most token s with *
* s.column geq t.column on the last line before t’s line containing *
* such a non-left-comment token s. *
* *
* Here are the descriptions of the different types of alignment. *
* *
* CommentInner: *
* Token t at position pos is CommentInner above-aligned with its *
* blocking token bt at position bpos iff: *
* / t is a right-comment *
* / bt is a right-comment *
* / t.column = bt.column *
* / / bt is not above-aligned with anything *
* / bt is CommentInner aligned with a token above it *
* *
* FirstNonLeftComment *
* If t is the first token on a line that is not a left-comment, and is *
* not a right-comment that is CommentInner aligned with a token above *
* it, then t is FirstNonLeftComment aligned with its covering token. *
* *
* Here are the descriptions of the different *
* kinds of alignment. *
22

179. * Any comment other than a left-comment or a right-comment is treated *
* like any other non-built-in token. We also define: *
* *
* - The COVERING TOKEN of a token t is the right-most token ct that *
* covers t on the last line (one with biggest line number) containing *
* a token that covers t, where a token t1 COVERS a token t2 if t1 *
* lies on an earlier line than t2 and t1.column leq t2.column. *
* However, if there is a DASH between ct and t, or *
* on the same line as ct, then t has no covering token. *
* (This definition has two versions, depending on whether or not *
* left-comments are ignored.) *
* *
* - The BLOCKING TOKEN of a token t is the left-most token s with *
* s.column geq t.column on the last line before t’s line containing *
* such a non-left-comment token s. *
* *
* Here are the descriptions of the different types of alignment. *
* *
* CommentInner: *
* Token t at position pos is CommentInner above-aligned with its *
* blocking token bt at position bpos iff: *
* / t is a right-comment *
* / bt is a right-comment *
* / t.column = bt.column *
* / / bt is not above-aligned with anything *
* / bt is CommentInner aligned with a token above it *
* *
* FirstNonLeftComment *
* If t is the first token on a line that is not a left-comment, and is *
* not a right-comment that is CommentInner aligned with a token above *
* it, then t is FirstNonLeftComment aligned with its covering token. *
* *
22

180. * *
* LeftComment: *
* If t is a left-comment token, then it is LeftComment aligned *
* with its covering token (where left-comments are visible). *
* *
* InfixInner: *
* Token t at position pos is InfixInner aligned with its covering *
* token ct at position cpos iff t is not FirstNonLeftComment aligned, *
* and both t and ct are built-in symbols with the same nonzero alignment *
* class. (The name InfixInner is misleading because non-infix symbols *
* like : get aligned by this mechanism.) *
* *
* AfterInfixInner: *
* Token t is After InfixInner aligned with the token above it iff *
* *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* at == the token to the right of alt *
* IN / t is not the first token on the line *
* / lt is InnerAligned with token alt above it *
* / alt is not the last token on its line. *
* / at is the covering token of t *
* / t.column = at.column *
* / at is not a comment *
* (The name AfterInfixInner means after InfixInner alignment. *
* Remember that some non-infix symbols get InfixInner aligned.) *
* *
* InfixArg: *
* Token t is InfixArg aligned with its covering token ct iff: *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* IN / t is not the first token on the line *
* / lt is the first non-left-comment token *
23

181. * *
* LeftComment: *
* If t is a left-comment token, then it is LeftComment aligned *
* with its covering token (where left-comments are visible). *
* *
* InfixInner: *
* Token t at position pos is InfixInner aligned with its covering *
* token ct at position cpos iff t is not FirstNonLeftComment aligned, *
* and both t and ct are built-in symbols with the same nonzero alignment *
* class. (The name InfixInner is misleading because non-infix symbols *
* like : get aligned by this mechanism.) *
* *
* AfterInfixInner: *
* Token t is After InfixInner aligned with the token above it iff *
* *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* at == the token to the right of alt *
* IN / t is not the first token on the line *
* / lt is InnerAligned with token alt above it *
* / alt is not the last token on its line. *
* / at is the covering token of t *
* / t.column = at.column *
* / at is not a comment *
* (The name AfterInfixInner means after InfixInner alignment. *
* Remember that some non-infix symbols get InfixInner aligned.) *
* *
* InfixArg: *
* Token t is InfixArg aligned with its covering token ct iff: *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* IN / t is not the first token on the line *
* / lt is the first non-left-comment token *
* LeftComment:
* If t is a left-comment token, then it is *
* LeftComment aligned with its covering *
* token. *
23

182. * *
* LeftComment: *
* If t is a left-comment token, then it is LeftComment aligned *
* with its covering token (where left-comments are visible). *
* *
* InfixInner: *
* Token t at position pos is InfixInner aligned with its covering *
* token ct at position cpos iff t is not FirstNonLeftComment aligned, *
* and both t and ct are built-in symbols with the same nonzero alignment *
* class. (The name InfixInner is misleading because non-infix symbols *
* like : get aligned by this mechanism.) *
* *
* AfterInfixInner: *
* Token t is After InfixInner aligned with the token above it iff *
* *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* at == the token to the right of alt *
* IN / t is not the first token on the line *
* / lt is InnerAligned with token alt above it *
* / alt is not the last token on its line. *
* / at is the covering token of t *
* / t.column = at.column *
* / at is not a comment *
* (The name AfterInfixInner means after InfixInner alignment. *
* Remember that some non-infix symbols get InfixInner aligned.) *
* *
* InfixArg: *
* Token t is InfixArg aligned with its covering token ct iff: *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* IN / t is not the first token on the line *
* / lt is the first non-left-comment token *
* LeftComment:
* If t is a left-comment token, then it is *
* LeftComment aligned with its covering *
* token. *
23

183. * *
* LeftComment: *
* If t is a left-comment token, then it is LeftComment aligned *
* with its covering token (where left-comments are visible). *
* *
* InfixInner: *
* Token t at position pos is InfixInner aligned with its covering *
* token ct at position cpos iff t is not FirstNonLeftComment aligned, *
* and both t and ct are built-in symbols with the same nonzero alignment *
* class. (The name InfixInner is misleading because non-infix symbols *
* like : get aligned by this mechanism.) *
* *
* AfterInfixInner: *
* Token t is After InfixInner aligned with the token above it iff *
* *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* at == the token to the right of alt *
* IN / t is not the first token on the line *
* / lt is InnerAligned with token alt above it *
* / alt is not the last token on its line. *
* / at is the covering token of t *
* / t.column = at.column *
* / at is not a comment *
* (The name AfterInfixInner means after InfixInner alignment. *
* Remember that some non-infix symbols get InfixInner aligned.) *
* *
* InfixArg: *
* Token t is InfixArg aligned with its covering token ct iff: *
* LET lt == the token to the left of t *
* alt == the token at position lt.aboveAlign *
* IN / t is not the first token on the line *
* / lt is the first non-left-comment token *
23

184. * Any comment other than a left-comment or a right-comment is treated *
* like any other non-built-in token. We also define: *
* *
* - The COVERING TOKEN of a token t is the right-most token ct that *
* covers t on the last line (one with biggest line number) containing *
* a token that covers t, where a token t1 COVERS a token t2 if t1 *
* lies on an earlier line than t2 and t1.column leq t2.column. *
* However, if there is a DASH between ct and t, or *
* on the same line as ct, then t has no covering token. *
* (This definition has two versions, depending on whether or not *
* left-comments are ignored.) *
* *
* - The BLOCKING TOKEN of a token t is the left-most token s with *
* s.column geq t.column on the last line before t’s line containing *
* such a non-left-comment token s. *
* *
* Here are the descriptions of the different types of alignment. *
* *
* CommentInner: *
* Token t at position pos is CommentInner above-aligned with its *
* blocking token bt at position bpos iff: *
* / t is a right-comment *
* / bt is a right-comment *
* / t.column = bt.column *
* / / bt is not above-aligned with anything *
* / bt is CommentInner aligned with a token above it *
* *
* FirstNonLeftComment *
* If t is the first token on a line that is not a left-comment, and is *
* not a right-comment that is CommentInner aligned with a token above *
* it, then t is FirstNonLeftComment aligned with its covering token. *
* *
23

185. * | | | | (* p *) *
* | | | | | *
* | | + y (* p *) *
* | | | *
* | | * r *
* | | *
* foo == *
* | *
* (* k *) *
* | *
* u + v *
* *
* For InfixInner and CommentInner alignment, a token’s belowAlign *
* field points to the token directly below it with which it is *
* aligned. *
* *
* For all alignment types, if a token t1 is aligned with a token *
* t2 above it, then t1.aboveAlign points to: *
* *
* IF t2 has no aboveAlign pointer THEN t2 *
* ELSE t2.abovealign. *
* *
* Thus, in the example above, the aboveAlign pointer for all the p *
* comments point to the first p comment. *
* *
* To define the types of alignment, we use the following definitions: *
* *
* - A LEFT-COMMENT is a comment that is the first token on its line but *
* not the last token on its line. (The comments (* j *) in the *
* example are left-comments.) For all the types of alignment except *
* CommentInner, left-comments are treated as if they didn’t exist. *
* *
23

186. * | | | | (* p *) *
* | | | | | *
* | | + y (* p *) *
* | | | *
* | | * r *
* | | *
* foo == *
* | *
* (* k *) *
* | *
* u + v *
* *
* For InfixInner and CommentInner alignment, a token’s belowAlign *
* field points to the token directly below it with which it is *
* aligned. *
* *
* For all alignment types, if a token t1 is aligned with a token *
* t2 above it, then t1.aboveAlign points to: *
* *
* IF t2 has no aboveAlign pointer THEN t2 *
* ELSE t2.abovealign. *
* *
* Thus, in the example above, the aboveAlign pointer for all the p *
* comments point to the first p comment. *
* *
* To define the types of alignment, we use the following definitions: *
* *
* - A LEFT-COMMENT is a comment that is the first token on its line but *
* not the last token on its line. (The comments (* j *) in the *
* example are left-comments.) For all the types of alignment except *
* CommentInner, left-comments are treated as if they didn’t exist. *
* *
* - A LEFT-COMMENT is a comment that is the *
* first token on its line but not the last *
* token on its line. *
23

187. * | | | | (* p *) *
* | | | | | *
* | | + y (* p *) *
* | | | *
* | | * r *
* | | *
* foo == *
* | *
* (* k *) *
* | *
* u + v *
* *
* For InfixInner and CommentInner alignment, a token’s belowAlign *
* field points to the token directly below it with which it is *
* aligned. *
* *
* For all alignment types, if a token t1 is aligned with a token *
* t2 above it, then t1.aboveAlign points to: *
* *
* IF t2 has no aboveAlign pointer THEN t2 *
* ELSE t2.abovealign. *
* *
* Thus, in the example above, the aboveAlign pointer for all the p *
* comments point to the first p comment. *
* *
* To define the types of alignment, we use the following definitions: *
* *
* - A LEFT-COMMENT is a comment that is the first token on its line but *
* not the last token on its line. (The comments (* j *) in the *
* example are left-comments.) For all the types of alignment except *
* CommentInner, left-comments are treated as if they didn’t exist. *
* *
23

188. And so on for 215 lines.
This is a mathematical-prose spec of alignment.
It consists of 6 rules plus explanation (comments).
24

189. And so on for 215 lines.
This is a mathematical-prose spec of alignment.
It consists of 6 rules plus explanation (comments).
24

190. And so on for 215 lines.
This is a mathematical-prose spec of alignment.
It consists of 6 rules plus explanation (comments).
24

191. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

192. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

193. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

194. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

195. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

196. Why did I write this spec?
It was a lot easier to understand and debug 6 rules
than 850 lines of code.
I did a lot of debugging of the rules, aided by debugging code
to report what rules were being used.
The few bugs in implementing the rules were easy to catch.
Had I just written code, it would have taken me much longer
and not produced formatting as good.
24

197. About 10 years later I enhanced the program to pretty-print
PlusCal code in comments.
A lot easier to modify a 6-rule spec than 850 lines of code.
Change to spec: Added one rule.
Changes to code:
Added 2 methods.
Changed one old method:
8 calls to an old method ! calls to a new method
Added 1 call to a new method.
Without spec, probably would have completely rewritten code.
25

198. About 10 years later I enhanced the program to pretty-print
PlusCal code in comments.
A lot easier to modify a 6-rule spec than 850 lines of code.
Change to spec: Added one rule.
Changes to code:
Added 2 methods.
Changed one old method:
8 calls to an old method ! calls to a new method
Added 1 call to a new method.
Without spec, probably would have completely rewritten code.
25

199. About 10 years later I enhanced the program to pretty-print
PlusCal code in comments.
A lot easier to modify a 6-rule spec than 850 lines of code.
Change to spec: Added one rule.
Changes to code:
Added 2 methods.
Changed one old method:
8 calls to an old method ! calls to a new method
Added 1 call to a new method.
Without spec, probably would have completely rewritten code.
25

200. About 10 years later I enhanced the program to pretty-print
PlusCal code in comments.
A lot easier to modify a 6-rule spec than 850 lines of code.
Change to spec: Added one rule.
Changes to code:
Added 2 methods.
Changed one old method:
8 calls to an old method ! calls to a new method
Added 1 call to a new method.
Without spec, probably would have completely rewritten code.
25

201. About 10 years later I enhanced the program to pretty-print
PlusCal code in comments.
A lot easier to modify a 6-rule spec than 850 lines of code.
Change to spec: Added one rule.
Changes to code:
Added 2 methods.
Changed one old method:
8 calls to an old method ! calls to a new method
Added 1 call to a new method.
Without spec, probably would have completely rewritten code.
25

202. Why not a formal spec?
Getting it right not that important.
It didn’t have to work on all corner cases.
There were no tools that could help me.
26

203. Why not a formal spec?
Getting it right not that important.
It didn’t have to work on all corner cases.
There were no tools that could help me.
26

204. Why not a formal spec?
Getting it right not that important.
It didn’t have to work on all corner cases.
There were no tools that could help me.
26

205. Why not a formal spec?
Getting it right not that important.
It didn’t have to work on all corner cases.
There were no tools that could help me.
26

206. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

207. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

208. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

209. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

210. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

211. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

212. What is Typical About This Spec
The spec is at a higher-level than the code.
It could have been implemented in any language.
No method or tool for writing better code would have
helped to write the spec
No method or tool for writing better code would have
made the spec unnecessary.
It says nothing about how to write code.
You write a spec to help you think about the problem
before you think about the code. 27

213. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

214. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

215. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

216. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

217. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

218. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

219. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

220. What is Not Typical About This Spec
It’s quite subtle.
95% of the code most people write requires less thought;
specs that are shorter and simpler suffice.
It’s a set of rules.
A set of rules/requirements/axioms is usually a bad spec.
It’s hard to understand the consequences of a set of rules.
The best way to write a functional spec is to write a function.
You can then check that the function implies any desired
requirements.
28

221. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

222. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

223. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

224. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

225. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

226. Specifying How to Compute a Function
Specifying what the pretty-printer should do was hard.
Figuring out how to implement it was easy.
Specifying what a sorting program should do is easy.
Figuring out how to implement it efficiently is hard
(if no one has shown you).
It requires thinking, which means writing a specification.
28

227. An example: Quicksort
A divide-and-conquer algorithm for sorting an array
A[0], . . . , A[N 1].
For simplicity, assume the A[i ] are numbers.
29

228. An example: Quicksort
A divide-and-conquer algorithm for sorting an array
A[0], . . . , A[N 1].
For simplicity, assume the A[i ] are numbers.
29

229. An example: Quicksort
A divide-and-conquer algorithm for sorting an array
A[0], . . . , A[N 1].
For simplicity, assume the A[i ] are numbers.
29

230. It uses a procedure Partition(lo; hi).
It chooses pivot in lo : : : (hi 1), permutes A[lo]; : : : ;A[hi]
to make A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi],
and returns pivot.
For this example, we don’t care how this procedure
is implemented.
30

231. It uses a procedure Partition(lo; hi).
It chooses pivot in lo : : : (hi 1), permutes A[lo]; : : : ;A[hi]
to make A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi],
and returns pivot.
For this example, we don’t care how this procedure
is implemented.
30

232. It uses a procedure Partition(lo; hi).
It chooses pivot in lo : : : (hi 1), permutes A[lo]; : : : ;A[hi]
to make A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi],
and returns pivot.
For this example, we don’t care how this procedure
is implemented.
30

233. Let’s specify Quicksort in pseudo-code.
procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

234. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

235. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

236. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

237. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

238. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
Informal: no formal syntax, no declarations, . . .
Easy to understand.
But is it really Quicksort?
31

239. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
Informal: no formal syntax, no declarations, . . .
Easy to understand.
But is it really Quicksort?
31

240. procedure Partition(lo; hi ) {
Pick pivot in lo : : : (hi 1);
Permute A[lo]; : : : ;A[hi ] to make
A[lo]; : : : ;A[pivot] A[pivot + 1]; : : : ;A[hi ];
return pivot; }
procedure QS(lo; hi ) { if (lo hi ) { p := Partition(lo; hi );
QS(lo; p);
QS(p + 1; hi ); } }
main { QS(0;N 1) ; }
But is it really Quicksort?
31

241. It’s the way Quicksort is almost always described.
But recursion is not a fundamental part of Quicksort.
It’s just one way of implementing divide-and-conquer.
It’s probably not the best way for parallel execution.
31

242. It’s the way Quicksort is almost always described.
But recursion is not a fundamental part of Quicksort.
It’s just one way of implementing divide-and-conquer.
It’s probably not the best way for parallel execution.
31

243. It’s the way Quicksort is almost always described.
But recursion is not a fundamental part of Quicksort.
It’s just one way of implementing divide-and-conquer.
It’s probably not the best way for parallel execution.
31

244. It’s the way Quicksort is almost always described.
But recursion is not a fundamental part of Quicksort.
It’s just one way of implementing divide-and-conquer.
It’s probably not the best way for parallel execution.
31

245. Problem: Write a non-recursive version of Quicksort.
Almost no one can do it in 10 minutes.
They try to “compile” the recursive version.
32

246. Problem: Write a non-recursive version of Quicksort.
Almost no one can do it in 10 minutes.
They try to “compile” the recursive version.
32

247. Problem: Write a non-recursive version of Quicksort.
Almost no one can do it in 10 minutes.
They try to “compile” the recursive version.
32

248. Solution:
Maintain a set U of index ranges on which
Partition needs to be called.
Initially, U equals fh0;N 1ig
We could write it in pseudo-code,
but it’s better to simply write Init and Next directly.
32

249. Solution:
Maintain a set U of index ranges on which
Partition needs to be called.
Initially, U equals fh0;N 1ig
We could write it in pseudo-code,
but it’s better to simply write Init and Next directly.
32

250. Solution:
Maintain a set U of index ranges on which
Partition needs to be called.
Initially, U equals fh0;N 1ig
We could write it in pseudo-code,
but it’s better to simply write Init and Next directly.
32

251. Solution:
Maintain a set U of index ranges on which
Partition needs to be called.
Initially, U equals fh0;N 1ig
We could write it in pseudo-code,
but it’s better to simply write Init and Next directly.
32

252. Init: A = any array of numbers of length N
^ U = fh0;N 1ig
Before writing Next, let’s make a definition:
Partitions(B; pivot; lo; hi) =
the set of arrays obtained from B by permuting
B[lo], . . . , B[hi] such that . . .
Next:
A relation between old values of A, U
and new values A0, U0.
33

253. Init: A = any array of numbers of length N
^ U = fh0;N 1ig
Before writing Next, let’s make a definition:
Partitions(B; pivot; lo; hi) =
the set of arrays obtained from B by permuting
B[lo], . . . , B[hi] such that . . .
Next:
A relation between old values of A, U
and new values A0, U0.
33

254. Init: A = any array of numbers of length N
^ U = fh0;N 1ig
Before writing Next, let’s make a definition:
Partitions(B; pivot; lo; hi) =
the set of arrays obtained from B by permuting
B[lo], . . . , B[hi] such that . . .
Next:
A relation between old values of A, U
and new values A0, U0.
33

255. Init: A = any array of numbers of length N
^ U = fh0;N 1ig
Before writing Next, let’s make a definition:
Partitions(B; pivot; lo; hi) =
the set of arrays obtained from B by permuting
B[lo], . . . , B[hi] such that . . .
Next:
A relation between old values of A, U
and new values A0, U0.
33

256. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

257. Next:
U6= fg Stop if U = fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

258. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

259. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

260. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

261. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

262. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

263. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

264. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
35

265. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
38

266. Why can (almost) no one find this version of Quicksort?
Their minds are stuck in code.
They can’t think at a higher level.
38

267. Why can (almost) no one find this version of Quicksort?
Their minds are stuck in code.
They can’t think at a higher level.
38

268. Why can (almost) no one find this version of Quicksort?
Their minds are stuck in code.
They can’t think at a higher level.
38

269. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Easy to write this as a formula.
39

270. Next:
U6= fg
^ Pick any hb; ti in U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Pick an arbitrary value
39

271. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Pick an arbitrary value is existential quantification.
39

272. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN Pick any p in b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Pick an arbitrary value is existential quantification.
39

273. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Pick an arbitrary value is existential quantification.
39

274. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 = Any element of Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Or sometimes
39

275. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 2 Partitions(A; p; b; t)
^ U0 = U with hb; ti removed and
hb; pi and hp+1; ti added
ELSE A0 = A
^ U0 = U with hb; ti removed
Or sometimes even simpler.
39

276. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 2 Partitions(A; p; b; t)
^ U0 = (U n fhb; tig) [ fhb; pi; hp+1; tig
ELSE A0 = A
^ U0 = U n fhb; tig
And so on.
39

277. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 2 Partitions(A; p; b; t)
^ U0 = (U n fhb; tig) [ fhb; pi; hp+1; tig
ELSE A0 = A
^ U0 = U n fhb; tig
A TLA+ formula.
39

278. Next:
U6= fg
^ 9 hb; ti 2 U :
IF b6= t
THEN 9 p 2 b : : (t1) :
A0 2 Partitions(A; p; b; t)
^ U0 = (U n fhb; tig) [ fhb; pi; hp+1; tig
ELSE A0 = A
^ U0 = U n fhb; tig
If you prefer pseudo-code. . .
39

279. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

280. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

281. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

282. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

283. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

284. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

285. PlusCal
Like a toy programming language.
Algorithm appears in a comment in a TLA+ module.
An expression can be any TLA+ expression.
Constructs for nondeterminism.
Compiled to an easy to understand TLA+ spec.
Can apply TLA+ tools.
40

286. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

287. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

288. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

289. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

290. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

291. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

292. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

293. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

294. Programs that Run Forever
I’ve been talking about programs that compute a function.
Programs that run forever usually involve concurrency:
– Operating systems.
– Distributed systems.
Few people can get them right by just thinking (and writing).
I’m not one of them.
We need tools to check what we do.
Use TLA+/ PlusCal.
41

295. The Other 95%
Prose
Most code is really simple.
41

296. The Other 95%
/***********************************************************
* CLASS ResourceFileReader *
* *
* A ResourceFileReader returns an object for reading a *
* resource file, which is a file kept in the same *
* directory as the tlatex.Token class. The constructor *
* takes a file name as argument. The object’s two public *
* methods are *
* *
* getLine() : Returns the next line of the file as a *
* string. Returns null after the last line. *
* *
* close() : Closes the file. *
***********************************************************/
42

297. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
General rule:
A spec of what the code does should say everything
that anyone needs to know to use the code.
43

298. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
General rule:
A spec of what the code does should say everything
that anyone needs to know to use the code.
43

299. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
General rule:
A spec of what the code does should say everything
that anyone needs to know to use the code.
43

300. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
General rule:
A spec of what the code does should say everything
that anyone needs to know to use the code.
43

301. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
General rule:
A spec of what the code does should say everything
that anyone needs to know to use the code.
43

302. Why did I write that spec?
To be sure I knew what the code should do before writing it.
Without writing a spec, I only thought I knew what it should do.
Later, I didn’t have to read the code to know what it did.
How the code worked was too simple to require a spec.
43

303. What programmers should know about thinking.
Everyone thinks they think.
If you don’t write down your thoughts,
you’re fooling yourself.
43

304. What everyone should know about thinking.
Everyone thinks they think.
If you don’t write down your thoughts,
you’re fooling yourself.
43

305. What everyone should know about thinking.
Everyone thinks they think.
If you don’t write down your thoughts,
you’re fooling yourself.
43

306. What everyone should know about thinking.
Everyone thinks they think.
If you don’t write down your thoughts,
you’re fooling yourself.
43

307. What programmers should know about thinking.
You should think before you code.
A spec is simply what you write before coding.
43

308. What programmers should know about thinking.
You should think before you code.
A spec is simply what you write before coding.
43

309. What programmers should know about thinking.
You should write before you code.
A spec is simply what you write before coding.
43

310. What programmers should know about thinking.
You should write before you code.
A spec is simply what you write before coding.
43

311. What code should you specify?
Any piece of code that someone else might want to
use or modify.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

312. What code should you specify?
Any piece of code that someone else might want to
use or modify.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

313. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

314. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

315. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

316. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

317. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

318. What code should you specify?
you
Any piece of code that someone else
might want to
use or modify in a month.
It could be:
An entire program or system.
A class.
A method.
A tricky piece of code in a method.
44

319. What should you specify about the code?
What it does.
Everything anyone needs to know to use it.
Maybe: how it does it.
The algorithm / high-level design.
44

320. What should you specify about the code?
What it does.
Everything anyone needs to know to use it.
Maybe: how it does it.
The algorithm / high-level design.
44

321. What should you specify about the code?
What it does.
Everything anyone needs to know to use it.
Maybe: how it does it.
The algorithm / high-level design.
44

322. What should you specify about the code?
What it does.
Everything anyone needs to know to use it.
Maybe: how it does it.
The algorithm / high-level design.
44

323. What should you specify about the code?
What it does.
Everything anyone needs to know to use it.
Maybe: how it does it.
The algorithm / high-level design.
44

324. How should you think about / specify the code?
Above the code level.
In terms of states and behaviors.
Mathematically, as rigorously / formally as necessary.
Perhaps with pseudo-code or PlusCal if specifying how.
45

325. How should you think about / specify the code?
Above the code level.
In terms of states and behaviors.
Mathematically, as rigorously / formally as necessary.
Perhaps with pseudo-code or PlusCal if specifying how.
45

326. How should you think about / specify the code?
Above the code level.
In terms of states and behaviors.
Mathematically, as rigorously / formally as necessary.
Perhaps with pseudo-code or PlusCal if specifying how.
45