Parameters — passing information in, by value or by reference

The banner procedure from the procedures lesson prints the same text every time it is called. That is fine for a banner, and useless for a receipt.

A receipt needs the customer's name and the amount — different on every sale. Write the procedure without them and it cannot print any particular sale. Write six versions, one per customer, and you are back to copy-and-paste.

Parameters solve this. They are the slots in the header where information comes in, so one procedure can work on different data on every call.

PROCEDURE PrintTotal(CustomerName : STRING, Amount : REAL)
  OUTPUT CustomerName, " owes ", Amount
ENDPROCEDURE

The header names two parameters, with a type for each:

• CustomerName : STRING — the first slot, holding text;
• Amount : REAL — the second slot, holding a decimal number.

To use it, supply two arguments in the same order, separated by commas:

CALL PrintTotal("Aisha", 24.50)

Now trace the call. CustomerName becomes "Aisha" and Amount becomes 24.50, so the body prints Aisha owes 24.50.

A second call with different arguments prints something different:

CALL PrintTotal("Ben", 9.99)     // Ben owes 9.99

Order matters, because the first argument always fills the first parameter. Swapping them here would try to store "Aisha" in a REAL, which is a type error.

Subprograms may take no parameters (the empty brackets you have already seen), one, or several — the syllabus allows all three, and you choose based on what the task needs.

Objective 11.3.6 is about using these terms precisely, so here they are on one real subprogram:

FUNCTION LineTotal(UnitPrice : REAL, Quantity : INTEGER) RETURNS REAL
  RETURN UnitPrice * Quantity
ENDFUNCTION

Cost ← LineTotal(2.50, 4)

Two traps:

• The interface is not the body. It is the contract: what goes in and what comes out.
• A procedure has no return value. It has a header and an interface, but nothing comes back, so "return value" only applies to functions.