procedures as parameters

[jmb@S1-B.ARPA (Jeff Broughton)]

You asked for an example of an algorithm where subprograms as parameters
are needed.  You correctly identified the issue as being whether or not
the identity of the procedure can be known at compile time.

My favorite example is that of a terminal interface.  A user logs into
a computer system and then tells it what type of terminal is to be used.
Several systems that I know of implement this kind of runtime binding
by having a set of procedure values that implement various functions,
e.g. clear_screen, put_line, etc.   Initially, the system initializes
the variables for a generic terminal.  When the user makes his selection,
the routines implementing the protocols specific to the terminal type
are assigned to the variables, and presto(!), terminal I/O is transformed
for another type.

Many might argue that this could be accomplished in other ways.  The
Unix termcap facility is one way; though I would argue that, in
effect, they accomplish the result by implementing pointers to
interpretive code.  Another is to have a global variable which defines
the type of the terminal, and have each terminal interface procedure
to examine the terminal type variable and dispatch to the corresponding
routine.

Ignoring issues of efficiency, my objection to the second approach is
that it requires the person who writes the terminal library to have
full knowledge of all the terminals that are to be supported, or
equivalently, that to add a new terminal type to the system, you have
to modify the code.  This is terrible modularity.

The usual counter argument is that for my example the names of all
the terminal types and hence the code for all the terminal types must
be in the system anyway; the difference is that it is on top of the
terminal library rather than below.  This is true in most computer
systems that we use today.  Being an old Multics programmer, however,
I am use to the notion of dynamic linking, where I can load a subroutine
by name from the file system and call it without every knowing its
name at compile time.

Fundamentally, what I am arguing is that the notion of "device independence"
requires procedure variables.  Sure, you can get around them, but you
really wish that you didn't have to.

By the way, this is really the same argument as in the earlier message
about the implementation of key-bindings in EMACS that appeared earlier
on Info-Ada.  Only the terms have been changed to aid the unfamiliar.