Re: Procedure types and dynamic binding

[stachour@umn-cs.CS.UMN.EDU (Paul Stachour)]

In article <1089@shuksan.UUCP> scott@shuksan.UUCP (Scott Moody) writes:
>> 
>> >    I haven't done an extended investigation of the literature, but
>> >    procedural variables in Algol-family languages would appear to
>> >    be a research topic
>>  <code not included> 
>> 
>> The final statement invokes the value of procvar, which is, of course,
>> "inner".  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.
>> 
>
In the Multics Implementation of PL/I, an procedure variable was
(not unsuprisingly) two items.  One was a pointer to the code
which was the procedure.  The 2nd was the "environment" of the
procedure at the point of the assignment.

Note that this allows:
   1) The code will thus update the correct "X" at any time,
      even when called from a highly-nested point, as it can find
      its "stack" and thus the "right x" to update.
   2) The code given in its original form to "detect" that there
      is no-such "X" to update, since there is no longer the
      version of "inner" that is "procvar" on the stack.  Detection
      of this stack-mismatch is easy in the example given, it is
      merely the fact that the stack is now "below" what it was at
      the point when the assignment "had effect".

  Of course, in the general case, where there may have been many calls
      in between, such a simple check would not work.  However, the simple
      matter of "gravestones", as used to detect dangling references,
      could be used with procedure-variables just as with naturals,
      or strings, or ...    ...Paul