Procedure Calls, Parameters, and Arguments

Think of a procedure as a worker you can hand a job to. You give it what it needs, it does the work, and it gives you back an answer. The things you hand over at the call site are arguments. Inside the procedure, each argument lands in a parameter, a variable that only exists for that one run of the procedure. The procedure's code never knows or cares where the arguments came from. It just uses the parameters as if they were ordinary variables.

The connection between argument and parameter is pure position and value, not name. When you call a procedure with two arguments, the first argument's value is copied into the first parameter, the second into the second, and so on. The parameter is a fresh box with its own label, filled with a copy of whatever value was sitting in the argument. That is why a parameter named amount works perfectly well when the caller passes in a variable named price, or a literal number, or the result of another expression. Only the value travels across; the name stays behind.

This is the hinge between writing procedures and actually using them. Once you can call a procedure correctly, matching arguments to parameters in order, you can reuse the same block of logic with endless different inputs, which is the whole point of abstraction. It also sets up why a procedure needs exactly as many arguments as it has parameters: each parameter needs a value to work with, and a missing argument leaves a parameter with nothing to hold, which causes an error rather than letting the procedure guess.