Unit 2: Until You Get It - Repeating - Foundations

The counted loop is for when you know how many times. Often you do not. You keep going until something happens: until the player guesses right, runs out of lives, or gives up. You cannot count that in advance.

Our guessing examples assume ASK supplies a valid number. Checking typed text or rejecting an invalid answer is extra behaviour, separate from repeating the work.

One guess, then stop

Here is the guessing game from Decisions:

Code

ASK "Guess my number? " INTO guess
IF guess < 7 THEN
  SHOW "Too low"
ELSE IF guess > 7 THEN
  SHOW "Too high"
ELSE
  SHOW "Correct!"
END

Output

Guess my number? 4
Too low

It tells you the guess was low, and then it is over. To guess again you run the whole thing again. We want several guesses within one round.

Repeat until you get it

Code

REPEAT
  ASK "Guess my number? " INTO guess
  IF guess < 7 THEN
    SHOW "Too low"
  ELSE IF guess > 7 THEN
    SHOW "Too high"
  END
UNTIL guess = 7
SHOW "Correct! Well done."

Everything between REPEAT and UNTIL happens over and over. At the bottom the computer asks its question. If the answer is no, it goes back to the top and runs the whole block again. Only when the answer is yes does it carry on to the line below.

Play it. Guess 4, then 9, then 7:

Output

Guess my number? 4
Too low
Guess my number? 9
Too high
Guess my number? 7
Correct! Well done.

This guessing-loop model checks after the work. A true test takes its normal completion path; a false test repeats. Input can also leave it waiting.

This is a useful game-loop model: do some work, check whether it is over, and repeat if it is not. Real games can organise repeated work differently; this small loop does not prescribe one structure for every game.

An exit we can reach is not a promise

The winning case is reachable: submitting 7 makes the condition true. That does not guarantee the player will submit it. Valid wrong guesses can keep the loop going. If the player has not submitted the next answer, ASK can wait without reaching the condition at all. Waiting for input differs from repeatedly executing a body that makes no progress.

The player submits 4, then 4 again. Does a reachable winning case guarantee this guessing loop will finish?

Show the explanation

No. Both guesses are wrong, so neither makes guess = 7 true. The program asks again and may wait for another submission. If the player later submits 7, it finishes normally. A few successful trials do not show that every possible input sequence finishes; the rule depends on the answers supplied.

A secret worth keeping

The answer is always seven. Across rounds, you already know what to guess. Choosing a secret for each round gives us another answer to search for.

RANDOM chooses a number from a range:

Code

LET secret = RANDOM 1 TO 10
REPEAT
  ASK "Guess my number? " INTO guess
  IF guess < secret THEN
    SHOW "Too low"
  ELSE IF guess > secret THEN
    SHOW "Too high"
  END
UNTIL guess = secret
SHOW "Correct! Well done."

RANDOM 1 TO 10 picks a whole number from 1 to 10, and both ends can come up. It uses the same range that FOR does, so there is nothing new to read.

Notice the tests changed too. They ask about secret now rather than about 7, so the program works for any secret in the range. A new round makes a fresh choice, but that choice may be the same number as before. Random does not mean different every time.

The assignment to secret comes before REPEAT, so it happens once when this round starts. Wrong guesses go back to ASK, not to the assignment. The secret stays the same while the player works towards it.

If the last round chose 7, can the next round choose 7 too?

Yes. Both choices are in the range. Seeing the same answer twice does not by itself show that the program is broken. Choosing a new secret after every wrong guess would be a different rule: the clues would no longer lead towards one fixed answer.

Choose a new secret in Sinclair BASIC shows how one machine makes these choices, including a way to repeat a sequence when testing. Its commands are Sinclair BASIC, not this pseudocode.

When it’s wrong, see why

It has not finished. First check whether it is waiting at ASK or handling more wrong guesses. Verify that a submitted winning guess reaches the exit. A reachable exit alone does not guarantee the input needed to take it.
It stops after one go. Something outside the loop ended the program, or the work you meant to repeat sits below the UNTIL rather than above it.
It leaves at the wrong moment. Read the question out loud. “Until the guess is seven” leaves exactly when the guess is seven, which is what you want. Turn it around and the loop either never runs twice or never stops.

What you’ve learnt

A loop-until repeats until something becomes true, for when you do not know how many times in advance.
The question sits at the bottom, so the work always happens at least once.
This do-it, check, repeat shape models one kind of repeated game work.
For a loop intended to finish, ask what makes it leave and whether that event is guaranteed, input-dependent or prevented by a bug.

What’s next

This loop asks its question at the bottom, after the work. In Unit 3 we meet the one that asks first, which can decide not to do the work at all.