01 | SOMETIMES THE FIRST ACTION MUST HAPPEN

A program needs a score from the user. Before it can decide whether the score is acceptable, it must receive one. If the first response is invalid, it asks again.

A REPEAT UNTIL loop puts the repeated work first and the test afterwards. This is post-condition iteration: the condition is checked after the body has executed.

The body runs at least once whenever execution reaches REPEAT. That makes it useful for tasks such as asking for input before checking whether to stop asking.

The most important contrast with WHILE is the meaning of true: WHILE continues when its condition is true, while UNTIL stops when its condition is true.

02 | READ THE REPEAT UNTIL FORMAT

Cambridge pseudocode uses REPEAT to start the body and UNTIL followed by its stopping condition to close it.

DECLARE Score : INTEGER
REPEAT
    OUTPUT "Enter a whole-number score from 0 to 10"
    INPUT Score
UNTIL Score >= 0 AND Score <= 10
OUTPUT "Accepted score: ", Score

Assume every supplied input is a whole number. The program prompts and receives Score, then checks whether it lies inside the inclusive range.

If the condition is true, the loop ends. If it is false, the body runs again and receives another score.

Unlike WHILE, this pattern does not need a first Score input before the loop. The body supplies Score before its first test.

03 | TRUE MEANS STOP, FALSE MEANS REPEAT

Read UNTIL Score >= 0 AND Score <= 10 as “repeat until this score is valid”. The condition describes completion.

Both bounds must hold, so the valid-range condition uses AND. Twelve violates the upper bound and minus one violates the lower bound.

The final accepted output occurs once, after the successful check. Invalid attempts are not reported as accepted.

Do not mentally apply the WHILE rule to UNTIL. A true UNTIL is the reason to stop, not the reason to run another iteration.

04 | AT LEAST ONCE DOES NOT MEAN TWICE

If the first supplied score is five, the body runs once, then the condition is true and repetition ends. There is one prompt, one input and one stopping-condition check.

The phrase “at least once” describes the minimum, not a compulsory extra attempt. A successful first response does not get requested again.

If the first response is invalid, more iterations occur. The number of attempts is determined by the responses, so a fixed FOR count is not a natural replacement for this retry behaviour.

Always consider both a valid first response and an invalid-then-valid sequence when testing input retries.

05 | TRACE A COUNTER VERSION

A counter example makes the position of the check easy to see.

DECLARE Count : INTEGER
Count ← 1
REPEAT
    OUTPUT Count
    Count ← Count + 1
UNTIL Count > 3
OUTPUT "Finished"

The condition uses the updated Count. The body outputs three, increases Count to four and only then tests the stopping condition.

There are three iterations and three UNTIL checks. The output Finished appears afterwards.

Compare the earlier WHILE example: its three body iterations required four checks because it tested once more before deciding not to enter the body.

06 | AN ALREADY-SATISFIED STOP CONDITION STILL FOLLOWS THE BODY

Start the same algorithm with Count equal to four. Count > 3 is already true mathematically, but REPEAT does not test it before entering the body.

The body first outputs four and increases Count to five. Then UNTIL Count > 3 is tested and the loop stops. There is one body iteration, not zero.

Two loops can behave alike for one starting state and differently for another. Do not claim they are interchangeable after testing only the normal case.

07 | STEP THROUGH BODY THEN CHECK

Choose a starting Count and predict the next event. Try one, three and four to see multiple, single and initially beyond-limit starts.

The trace begins with a body output, not a condition check. It then shows the update and the UNTIL result, followed by common code when the loop stops.

08 | CONVERT THE CONDITION, NOT JUST THE KEYWORD

A WHILE range retry continues while invalid. The REPEAT version stops when valid.

Changing WHILE to UNTIL while keeping the invalidity condition would make the retry stop for invalid input. A score of twelve could immediately terminate the wrong REPEAT loop.

The structure also changes the placement of the first input. WHILE needs a value before its first condition; REPEAT can obtain the value inside the first body execution.

To translate correctly, identify the repeated job, its start state, its continuation or stopping rule, and the location of input and processing.

09 | A POST-CONDITION BODY STILL NEEDS PROGRESS

A REPEAT loop can be infinite if its stopping condition never becomes true.

Count ← 1
REPEAT
    OUTPUT Count
UNTIL Count > 3

Count remains one. The body outputs one, then checks a false stopping condition, and repeats forever under these instructions.

Add the relevant update inside the body: Count ← Count + 1. With the correct update, later checks can eventually see Count greater than three.

For a retry loop, the next INPUT provides new state. If you ask again but forget to receive a new value, the old invalid input remains and the loop cannot complete.

A post-condition check does not magically ensure termination. Explain what changes and why the stopping condition can become true.

10 | SENTINEL PROCESSING NEEDS A GUARD

In the WHILE sentinel example, a test before the body excluded minus one from processing. In REPEAT, input and processing happen before UNTIL, so you must guard processing inside the body.

DECLARE Amount : INTEGER
DECLARE Total : INTEGER
Total ← 0
REPEAT
    OUTPUT "Enter an amount, or -1 to stop"
    INPUT Amount
    IF Amount <> -1
      THEN
        Total ← Total + Amount
    ENDIF
UNTIL Amount = -1
OUTPUT "Total: ", Total

Assume each supplied value is a non-negative whole number or the sentinel minus one. INPUT receives the value, IF decides whether it is an amount to add, and UNTIL decides whether another iteration is needed.

The stop value reaches the body, but the guard prevents it contributing to Total. Simply placing UNTIL after an unconditional addition would be too late to exclude it.

11 | DISTINGUISH BODY ITERATIONS FROM ITEMS PROCESSED

The REPEAT body runs four times because each pass receives an input, including the sentinel pass. Only three amounts are processed. That differs from the primed WHILE pattern, whose sentinel is tested before another body entry.

If minus one is the first input, the REPEAT body still executes once, but it processes zero amounts and outputs a total of zero.

A valid zero amount changes no sum but is still an item. If the task also counts entries, increment the count inside the same non-sentinel guard as the addition.

12 | SELECT THE RIGHT WORK TO KEEP INSIDE

In validation, receive attempts inside the loop and use the accepted value afterwards. For example, add an accepted class attendance to a total after its range retry has finished, not on every invalid attempt.

In a sentinel-controlled REPEAT, receive the current value inside the body, process it only if it is not the sentinel, then test the stop condition.

The keyword alone does not determine correctness. The order and placement of input, checks and processing determine which values affect the result.

Common final results normally belong after UNTIL so they display once after completion, rather than after every attempt.

13 | TEST THE FIRST ATTEMPT AND THE STOPPING BOUNDARY

For a zero-to-ten score retry, test zero and ten as accepted endpoints. Test minus one followed by zero, and eleven followed by ten, to check rejection and replacement.

For the counter version, starts one, three and four reveal the body-before-check behaviour. Start three outputs three once, updates to four and stops. Start four also runs once but outputs four.

For sentinel processing, test several values followed by the sentinel and the sentinel as the first response. Check both the number of received inputs and the items actually added or counted.

These tests can expose a wrong condition sense, a missing update or an unconditional addition of the sentinel.

14 | COMMON REPEAT UNTIL MISTAKES

True treated as continue: UNTIL stops when true.

Initial test imagined: the first body runs before any UNTIL evaluation.

WHILE condition copied unchanged: a continuation condition usually needs a corresponding stopping condition and adjusted structure.

Sentinel added before its test: use a guard to exclude it from processing.

Attempts mistaken for accepted items: a body can receive a rejected or sentinel value without processing an ordinary item.

Input or progress missing: the state may never change to satisfy completion.

Extra closing keyword: UNTIL closes the Cambridge REPEAT structure; do not add ENDREPEAT.

15 | EXPLAIN BODY, CHECK AND CONSEQUENCE

For range retry: “The body receives a score before testing it. If the valid-range condition is false, another input is requested; when it is true, the loop ends and the accepted score is output.”

For sentinel processing: “The IF guard excludes minus one from the sum because the body receives that value before the stopping check. UNTIL then detects the sentinel and prevents another iteration.”

Explain the condition’s sense as well as its position. Both are needed to distinguish pre-condition and post-condition repetition.

The next lesson brings FOR, WHILE and REPEAT UNTIL together so you can choose and compare them for different scenarios.