Editing The I/O problem (section)

== The procedural boundary ==

In theory, a procedure could be given one or more input registers as arguments and write the result directly to an output register. So if the contents of the input registers change while the procedure is running, its eventual result could be based on some combination of old and new input data. This, <i>while possibly annoying</i>, is to be expected: procedures are allowed to provide different results for the same arguments.

In practice, one or more procedures <b>are</b> given most, if not all I/O registers along with all available memory addresses. Together with other procedures (and some functions), they form the kernels of most contemporary operating systems.

But for a function, such conspicuous variability in its given arguments is untenable:
* while a function is being evaluated to obtain a result,
* and the result is still being used (it may contain arguments, or be one of them),
the values of its arguments must be kept constant for the result to be correct.

This requirement presents serious difficulties for the direct use of I/O registers with functions:
* evaluation of a function can take an arbitrarily-long time to complete,
* and providing the result to an external entity could also be slow to finish (the result could be large).

In essence, if a function were to use I/O registers directly, they would have to behave like memory addresses. But that is contrary to the intended purpose of I/O registers! Therefore it is usually easier for the exchange of data between programs and I/O registers to be managed by procedures (or actions in [[House]]), with most other work being done by functions.