procedure types

procedure types

[Mats Weber]

Bill Wolfe writes :

>  Quick question: assuming the idea of a specification is expanded to
>  include all externally accessible objects, what is the source of
>  the insecurity?

Could you please clarify your question (may be with an example). Thanks

Mats Weber
Swiss Federal Institute of Technology
EPFL DI LITh
1015 Lausanne
Switzerland

e-mail : madmats@elma.epfl.ch

Re: procedure types

[William Thomas Wolfe,2847,]

From article <890119102705.20e0039e@elcc.epfl.ch>, by madmats@elma.epfl.ch (Mats Weber):
> Bill Wolfe writes :
> 
>>  Quick question: assuming the idea of a specification is expanded to
>>  include all externally accessible objects, what is the source of
>>  the insecurity?
> 
> Could you please clarify your question (may be with an example). Thanks

    Well, various references were made to some sort of insecurity arising
    from taking a inner-nested procedure and assigning it to a procedural
    variable, and then using it somewhere outside of its textual context.

    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.

    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.



                                          Bill Wolfe

                                   wtwolfe@hubcap.clemson.edu
 

Re: procedure types

[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

Re: procedure types

[William Thomas Wolfe,2847,]

From article <5865@medusa.cs.purdue.edu>, by 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.  [...] 
> 
> 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?

   If procedural variables are to exist, yes.  If there are no procedural
   variables, then the dynamic binding would not be necessary, but the
   other advantages would remain.

   I'm not yet convinced that there's a need for procedural variables,
   and I'd like to see an example of where the "active objects" Barry
   talked about would be appropriate; if you can give such an example
   of a realistic situation in which procedural variables are intuitively
   natural and necessary, then the cost of dynamic binding might be justified.



                                               Bill Wolfe

                                        wtwolfe@hubcap.clemson.edu

procedure types

[Mats Weber]

I think there is one good reason why procedure types should not be included in
the Ada language: A secure implementation of procedure types must restrict
their use to global procedures (that is, procedures that are not nested in
other procedures or tasks), as is the case in Modula-2.

Such a rule would violate the uniformity of the language (in Ada 83, anything
can be declared in any declarative region, no matter how deeply nested the
region is).

Mats Weber
Swiss Federal Institute of Technology
EPFL DI LITh
1015 Lausanne
Switzerland

e-mail : madmats@elma.epfl.ch