Return Values and the Flow of Control

A procedure call pauses the line of code that's running. Control leaves the caller, jumps into the procedure, and runs every instruction inside it. If the procedure hits a RETURN statement, control immediately jumps back to the exact spot in the caller where the call happened, carrying the returned value with it. The caller then treats that call as if it were just the value itself, and finishes executing its own line.

This matters because it's the only way a procedure can hand back something useful. A procedure that runs DISPLAY shows a value on the screen, but that's a side effect, not a handoff. The caller gets nothing to store, compare, or compute with. Only an explicit RETURN gives the caller a value it can plug into an expression, pass to another procedure, or save in a variable.

RETURN also ends the procedure the moment it executes, even if more lines sit below it. That's useful for branching logic: a procedure can check a condition early, RETURN one value if it's true, and only run the remaining code if it's false. This flow of control connects directly to how lists and loops call procedures repeatedly, and sets up why procedures with no RETURN are used only for their side effects, like displaying or changing state, never for their output.