madmats@elma.epfl.ch (Mats Weber) (01/09/89)
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
madmats@elma.epfl.ch (Mats Weber) (01/19/89)
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
billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (01/20/89)
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
rjh@cs.purdue.EDU (Bob Hathaway) (01/20/89)
> 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
billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (01/20/89)
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