* procedure types
@ 1989-01-09 12:37 Mats Weber
0 siblings, 0 replies; 5+ messages in thread
From: Mats Weber @ 1989-01-09 12:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* procedure types
@ 1989-01-19 9:27 Mats Weber
1989-01-19 18:07 ` William Thomas Wolfe,2847,
0 siblings, 1 reply; 5+ messages in thread
From: Mats Weber @ 1989-01-19 9:27 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: procedure types
1989-01-19 9:27 procedure types Mats Weber
@ 1989-01-19 18:07 ` William Thomas Wolfe,2847,
1989-01-19 19:55 ` Bob Hathaway
0 siblings, 1 reply; 5+ messages in thread
From: William Thomas Wolfe,2847, @ 1989-01-19 18:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: procedure types
1989-01-19 18:07 ` William Thomas Wolfe,2847,
@ 1989-01-19 19:55 ` Bob Hathaway
1989-01-19 21:53 ` William Thomas Wolfe,2847,
0 siblings, 1 reply; 5+ messages in thread
From: Bob Hathaway @ 1989-01-19 19:55 UTC (permalink / raw)
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: procedure types
1989-01-19 19:55 ` Bob Hathaway
@ 1989-01-19 21:53 ` William Thomas Wolfe,2847,
0 siblings, 0 replies; 5+ messages in thread
From: William Thomas Wolfe,2847, @ 1989-01-19 21:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1989-01-19 21:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-01-19 9:27 procedure types Mats Weber
1989-01-19 18:07 ` William Thomas Wolfe,2847,
1989-01-19 19:55 ` Bob Hathaway
1989-01-19 21:53 ` William Thomas Wolfe,2847,
-- strict thread matches above, loose matches on Subject: below --
1989-01-09 12:37 Mats Weber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox