Procedure variables

[worley@compass.UUCP (Dale Worley)]

   From: firth@sei.cmu.edu  (Robert Firth)
   Subject: Procedure types and dynamic binding

   [discussion of problems that can arise with procedure-valued variables]
   The call of inner references the variable X declared in outer,
   which no longer exists.  This is the equivalent of the "dangling reference"
   problem when the address of a local variable is assigned to a global
   pointer.

   Many solutions have been proposed; the cleanest in my opinion is that of
   Modula-2, which does not allow an "inner" procedure to be assigned to a
   variable.

There are two other clean solutions which I know of.  One used by
Algol 68 is that you can't assign a procedure-value to any variable
that would allow it to be exported out of the procedure or block that
created the variables that it refers to.  Of course, in general this
has to be checked at runtime.  But it lets you do most of what you
want to do with procedures with very little overhead (if you disable
the runtime checks!).

The other solution is used by Scheme, and allows the procedure-value
to carry along with it the variables from its environment that are
necessary for its execution.  This requires that the procedure-value
(in general) be represented by more than just a pointer to its code,
but it can be used to implement a number of useful things that can't
be easily expressed in most programming languages.  (For instance,
true object-oriented programming.)  Efficient implementation of this
system requires good global analysis of the program, which has been
done in a few Scheme compilers.

Contrary to popular belief, procedure-valued variables are not "poorly
structured".  They do have the problem that you can't determine
(statically) where control is going, but presumably the procedure is
an encapsulation of some conceptually well-defined operation, and so
you know what it does, even if you don't know what code is doing it.

Dale