Re: procedure types

[rjh@cs.purdue.EDU (Bob Hathaway)]

>    My idea was that if for example a procedure referenced an externally
>    defined variable X, then that and all other externally referenced
>    objects should form part of the procedure's specification.  Then if
>    the procedure was called in a context which did not include X, of
>    the type that X was expected to be, then an error similar to a 
>    "missing parameter" error would occur.  Since a specification now
>    includes all possible interactions between a procedure and its context, 
>    we should then be free to pass procedures around without restriction.

Typically, a procedure's environment is determined statically from its
declared environment and not dynamically at runtime.  There is also
binding of other objects X such as functions and packages, etc.  Your
approach appears to use dynamic binding of the procedural variables
environment; do you think this approach is better than the usual static 
binding rules of Ada objects?


>    Other advantages would accrue in that during debugging and maintenance,
>    it is frequently difficult to determine which global variables a 
>    procedure is referencing.  By requiring that a shield exist by default,
>    and providing a facility for poking holes in that shield, the compiler
>    can provide a guarantee that the list of externally referenced objects
>    is valid, eliminating the fact that one can never really be certain
>    that the documentation regarding what this procedure allegedly accesses
>    bears any relationship to the procedure's actual behavior.

I agree entirely.  In Modula, this can be accomplished by encapsulating a
procedure in a local module and exporting the procedure.  The import/export
mechanism can be used to provide explicit access to global variables.  But 
this is a clumsy approach and a primitive mechanism would be better.

                                             Bob Hathaway
                                             rjh@purdue.edu