These words in TCL are all that the tire-changing robot (the imaginary human computer) understands. Any other command that’s not part of Tire-Changing Language generates a blank stare of incomprehension from the human tire-changing processor.
Now it’s time to convert the algorithm, written in everyday English, into a program written in Tire-Changing Language. It’s not as easy as it might seem. Take, for example, the phrase, “Remove the lug nuts.” Actually, quite a bit is left unstated in that sentence. The word remove is not in the processor’s vocabulary. In addition, a wrench (which is a word the computer knows) is never mentioned in that phrase, though we all know that a wrench must be involved. We can’t assume that the computer knows what we know.
(If you haven’t changed a flat tire – and didn’t know that a wrench is required to remove lug nuts, or what a lug nut is – then just play along for now. You’ll figure it out.)
The following steps implement the phrase “Remove a lug nut” using only the verbs and nouns contained in Tire-Changing Language:
1. Grab wrench.
2. Move wrench to lug nut.
3. Turn wrench counterclockwise five times.
4. Move wrench to toolbox.
5. Release wrench.
At this point, consider these aspects of the syntax (required word order) implied in this example of Tire-Changing Language:
✔ Every command starts with a single verb.
✔ The verb grab requires a single noun as its object.
✔ The verb turn requires a noun, a direction, and a count of the number of turns to make.
Even so, the program snippet should be easy enough to read (after all, this isn’t a book about Tire-Changing Language).
The program begins at Step 1 and continues through each step in turn until reaching Step 5. In programming terminology, we say that the program flows from Step 1 through Step 5. Of course, the program’s not going anywhere – the processor is doing all the work – but program flow is a common term for this smooth execution of steps.
Even a cursory examination of this program reveals a problem: What if there is no lug nut? I suppose it’s harmless to spin the wrench around a bolt with no nut on it, but doing so wastes time and isn’t my idea of a good solution. The Tire-Changing Language needs a branching capability that allows the program to take one path or another in response to external conditions. We need an IF statement such as the following:
1. Grab wrench.
2. If lug nut is present
3. {
4. Move wrench to lug nut.
5. Turn wrench counterclockwise five times.
6. }
7. Move wrench to toolbox.
8. Release wrench.
The program starts with Step 1 just as before, and grabs a wrench. In the second step, however, before the program waves the wrench uselessly around an empty bolt, it checks to see if a lug nut is present. If so, flow continues with Steps 3, 4, and 5 as before. If not, however, program flow skips these unnecessary steps and goes straight on to Step 7 to return the wrench to the toolbox.
In computerese, you say that the program executes the logical expression “is lug nut present?” This expression returns either a true (yes, the lug nut is present) or a false (no, there is no lug nut there).
I realize that there’s no need to grab a wrench if there’s no lug nut to remove, but work with me here.
This improved program still has a problem: How do you know that five turns of the wrench will be sufficient to remove the lug nut? It most certainly will not be enough for most of the tires with which I am familiar. You could increase the number of turns to something that seems likely to be more than enough, say, 25 turns. If the lug nut comes loose after the 20th turn, for example, the wrench will turn an extra five times. This is a harmless but wasteful solution.
A better approach is to add some type of “loop and test” statement to the Tire-Changing Language:
1. Grab wrench.
2. If lug nut is present
3. {
4. Move wrench to lug nut.
5. While (lug nut attached to car)
6. {
7. Turn wrench counterclockwise one turn.
8. }
9. }
10. Move wrench to toolbox.
11. Release wrench.
Here the program flows from Step 1 through Step 4 just as before. In Step 5, however, the processor must make a decision: Is the lug nut attached? On the first pass, assume that the answer is yes so the processor will execute Step 7 and turn the wrench counter-clockwise one turn. At this point, the program returns to Step 5 and repeats the test. If the lug nut is still attached, the processor repeats Step 7 before returning to Step 5 again. Eventually, the lug nut will come loose and the condition in Step 5 will return a false. At this point, control within the program will pass to Step 9, and the program will continue as before.
This solution is superior to its predecessor: It makes no assumptions about the number of turns required to remove a lug nut. It doesn’t waste effort by requiring the processor to turn a lug nut that is no longer attached, nor does it fail by leaving a lug nut only half-removed.
As nice as this solution is, however, it still has a problem: It removes only a single lug nut. Most medium-size cars have five nuts on each wheel. We could repeat Steps 2 through 9 five times, once for each lug nut. However, this doesn’t work very well either. Most compact cars have only four lug nuts, and large pickups have up to eight.
The following program expands our grammar to include the ability to loop across lug nuts. This program works irrespective of the number of lug nuts on the wheel:
1. Grab wrench.
2. For each lug bolt on wheel
3. {
4. If lug nut is present
5. {
6. Move wrench to lug nut.
7. While (lug nut attached to car)
8. {
9. Turn wrench counterclockwise one turn.
10. }
11. }
12. }
13. Move wrench to toolbox.
14. Release wrench.
This program begins just as before with the grabbing of a wrench from the toolbox. Beginning with Step 2, however, the program loops through Step 12 for each lug-nut bolt on the wheel.
Notice how Steps 7 through 10 are still repeated for each bolt. This is known as a nested loop.