Class 22: Program Documentation

Held: Tuesday, 25 February 2003

Summary: Today we consider ways to use assertions to document and describe programs.

Related Pages:

• EBoard.

Due

• Gries 6.

Notes:

• This outline was created a day late. Sorry.

Overview:

• Using Assertions.
• Notation.
• Assertions about Assignments.
• Assertions about Sorting.

Using Assertions

• As you know, we're developing all of this theory about assertions so that we can use them in programs.
• There are at least two key ways we'll use assertions.
• Most frequently, we'll use assertions to indicate what we plan for our code to do.
  • In this case, we write preconditions and postconditions for our procedures (or statements).
  • We can then use some careful reasoning to show that the code plus the preconditions lead to the postconditions.
  • Although we haven't done the proof part in other courses, we've discussed care in writing preconditions and postconditions.
• Sometimes, we'll use assertions to formally define the statements of our language.

Notation

• Just as in the case of informal assertions, we need to be careful that someone doesn't try to meet our postconditions by doing something other than we expect.
• For example, if the postcondition is simply { x=y }, one can reach the postcondition by simply setting both x and y to 0.
• To indicate constant values, we use capital letters.

Assignment

• We'll consider (as a group) how we might use assertions to indicate the meaning of assignment operations.

Sorting

• There are two primary ways to think about sorting:
  • sort(source,destination) puts the result of sorting into destination (and doesn't change source).
  • sort!(source) sorts in place.
• We'll consider (as a group) how we might use assertions to indicate the desired results of a sorting procedure.
• Along the way, we'll need to consider the formal specification of permute(x,y).