Re: procedural variables

[edwards@rutabaga.cis.ohio-state.edu (stephen edwards)]

In article <1991Feb16.141232.1@elcgl.epfl.ch> madmats@elcgl.epfl.ch writes:

>After all, the 'need' for procedure variables has only
>become serious since people have been trying to interface x-toolkits
>with Ada (callbacks), but does that mean that callbacks are the right
>way of doing it ?

This isn't quite correct.  Ironically, procedure _variables_ (in Ada)
aren't even needed for X callbacks, as virtually all Ada-to-C X interfaces
illustrate.  One only need pass an indirect reference to an Ada procedure
on to the C code.  For this purpose, there isn't need of Ada-manipulable
procedure variables.  (this would not be true when interfacing to an all
Ada implementation of X, of course.)

But this statement, and a few of the past articles on this thread which
point out that generics can be used in place of many forms of procedure
variables, misses what may be the heart of the 'need.'  Remember "table-
driven programming"?  Maybe you learned it by a different name, like
"data-driven computation", computing with "dispatch tables", or something
else.  But the point is that real, live procedure variables _can be
placed in data structures_.  These data structures can be manipulated in
arbitrary ways, and the final result can be passed to something that is,
at heart, an interpreter.

Now, that final "interpreting" routine has programmable semantics.  What
actions it performs can be controlled simply by placing procedure variables
pointing to new routines into the data structure.  How much the semantics
can be altered (and how easily) is determined by the actual structure of
the "table", how it is manipulated, the interpretation strategy, etc.

This is a fairly conventional, but very powerful technique.  It allows
one to completely separate the "driver"/interpreter/execution framework
from the "action routines"/"evaluation functions/etc, and pushes the time
at which the binding between these two distinct parts are made off until
run-time.  It's common in highly programmable/configurable software tools
which load a configuration file when they are run--this file is basically
a description of the interpreted data structure in some abstract form.

Without procedure variables, you can't completely separate the driver
from the action routines.  This makes the software somewhat less flexible
and also more difficult to maintain.

A few posters have hinted at such "alternative" uses for procedure variables,
but no one had quite  come right out and said it (if they did and I missed
it, I apologize for the redundancy).


				-- Steve

Stephen Edwards					U.S. mail: 372 Jones Tower
e-mail    : edwards@cis.ohio-state.edu	           	   101 Curl Drive
home phone: (614)-293-0842			 	   Columbus, OH  43210