Re: procedures as parameters

[MHJohnson@HI-MULTICS.ARPA (Mark Johnson)]

  I'd like to amplify the response of jmb@s1-b.arpa by describing
Multics and by describing a graphics library implementation (Template on
VAX/VMS).

  On Multics, the operating system has a mechanism to automatically
search several directories to find a procedure AT RUN TIME.  This
usually makes the first reference to a procedure slow (say .5sec) but
makes subsequent references run at full speed.  This is a very useful
feature for supporting multiple versions of tools (eg KERMIT, test
software, & other stuff) and allows the incremental development of
software.  I know this is a very brief description, but look at
Organick's (sp?)  book on Multics or the article in Datamation (April
issue I think) for more details.

  On VAX/VMS, there is a concept of `shared libraries'.  If you follow
some special procedures, the linker and loader will work to allow you to
make updates to subroutines in a shared library without relinking all
the programs that reference the library.  A VMS implementation of
Template uses this to create a number of shared libraries, one for each
supported device.  You run a program (IDENT) to define a logical name
that identifies the shared library that supports your graphics device.
All of the programs that use those libraries can move from one device to
another without recoding or relinking.  New devices can be added at will
as long as they adhere to the calling standards and are built in the
same way as the other shared libraries.

  In both cases, the operating system supports the concept of `run-time'
binding of procedures.  In both cases, argument validation (number and
type) can be performed if necessary (usually ignored w/ fatal results
though).  In both cases, the user of the system is given greater
flexibility by postponing the actual procedure call binding to run-time.
In both cases, you do not need procedure variables to implement this
run-time binding, but you do need to understand how the operating system
works and you end up with very system specific implementations.

  --Mark Johnson <MHJohnson @ HI-MULTICS>