5.5.3 Procedural Iterators
{
AI12-0189-1}
A
procedural_iterator
invokes a user-defined procedure, passing in the body of the enclosing
loop_statement
as a parameter of an anonymous access-to-procedure type, to allow the
loop body to be executed repeatedly as part of the invocation of the
user-defined procedure.
Syntax
Name Resolution Rules
Legality Rules
Static Semantics
{
AI12-0344-1}
In a procedural iterator, the Parallel_Calls aspect (see
9.10.1)
of the loop body procedure is True if the reserved word
parallel
occurs in the corresponding loop statement, and False otherwise.
{
AI12-0189-1}
{
AI12-0326-2}
{
AI12-0344-1}
The following aspects may be specified for a callable entity
S
that has exactly one formal parameter of an anonymous access-to-subprogram
type:
Allows_Exit
The Allows_Exit aspect is of type Boolean. The specified value shall
be static. The Allows_Exit aspect of an inherited primitive subprogram
is True if Allows_Exit is True either for the corresponding subprogram
of the progenitor type or for any other inherited subprogram that it
overrides. If not specified or inherited as True, the Allows_Exit aspect
of a callable entity is False. For an entry, only a confirming specification
of False is permitted for the Allows_Exit aspect.
Reason: An entry does not allow exit,
because implementing a transfer of control out of a task or protected
entry creates unnecessarily complex dynamic semantics.
Specifying the Allows_Exit aspect to be
True for a subprogram indicates that the subprogram
allows exit,
meaning that it is prepared to be completed by arbitrary transfers of
control from the loop body procedure[, including propagation of exceptions.
A subprogram for which Allows_Exit is True should use finalization as
appropriate rather than exception handling to recover resources and make
any necessary final updates to data structures].
Aspect Description for Allows_Exit:
An indication of whether a subprogram will operate correctly for
arbitrary transfers of control.
Ramification: A subprogram that does
not need cleanup satisfies the requirements, and thus can specify Allows_Exit
as True. If a subprogram
S allows exit, it cannot expect to get
control other than via finalization if the loop body procedure initiates
a transfer of control as part of a
procedural_iterator.
In particular, exception handlers in
S, even
when others
handlers, will not be executed when a transfer of control occurs. The
mechanism that the implementation uses to implement such transfers of
control needs to avoid triggering exception handlers.
Parallel_Iterator
The Parallel_Iterator aspect is of type Boolean. The specified value
shall be static. The Parallel_Iterator aspect of an inherited primitive
subprogram is True if Parallel_Iterator is True either for the corresponding
subprogram of the progenitor type or for any other inherited subprogram
that it overrides. If not specified or inherited as True, the Parallel_Iterator
aspect of a callable entity is False.
{
AI12-0189-1}
{
AI12-0442-1}
Specifying the Parallel_Iterator aspect to be True for a callable entity
indicates that the entity is allowed to invoke the loop body procedure
from multiple distinct logical threads of control. The Parallel_Iterator
aspect for a subprogram shall be statically False if the subprogram allows
exit.
Aspect Description for Parallel_Iterator:
An indication of whether a subprogram may use multiple threads of
control to invoke a loop body procedure.
Reason: Permitting exit from a parallel
procedural iterator introduces additional semantic and implementation
complexity.
Legality Rules
{
AI12-0189-1}
{
AI12-0326-2}
If a callable entity overrides an inherited dispatching subprogram that
allows exit, the overriding callable entity also shall allow exit. If
a callable entity overrides an inherited dispatching subprogram that
has a True Parallel_Iterator aspect, the overriding callable entity also
shall have a True Parallel_Iterator aspect.
Ramification: Since an entry never allows
exit, attempting to implement an allows exit subprogram with a task or
protected entry is always illegal. However, the Parallel_Iterator aspect
can be applied to an entry, so a subprogram with the Parallel_Iterator
aspect True can be implemented by an entry.
{
AI12-0326-2}
If the actual parameter of an anonymous access-to-subprogram type, passed
in an explicit call of a subprogram for which the Parallel_Iterator aspect
is True, is of the form
P'Access, the designated subprogram
P
shall have a Parallel_Calls aspect True (see
9.10.1).
Reason: An
accept_statement
is not allowed in a procedure (see 9.5.2), it has to be directly in a
task_body.
Since the loop body here is implemented as a procedure, we can't allow
accept_statements
there, either, even if the loop itself is directly in a
task_body.
Dynamic Semantics
Proof: The stated dynamic semantics are
implied by the static semantics given above and the bounded errors given
below.
Bounded (Run-Time) Errors
{
AI12-0326-2}
{
AI12-0445-1}
If the callable entity identified in the
iterator_procedure_call
allows exit, then it is a bounded error for a call of the loop body procedure
to be performed from within an abort-deferred operation (see
9.8),
unless the entire
loop_statement
was within the same abort-deferred operation. If detected, Program_Error
is raised at the point of the call; otherwise, a transfer of control
from the
sequence_of_statements
of the
loop_statement
will not necessarily terminate the
loop_statement,
and the loop body procedure can be called again.
{
AI12-0326-2}
{
AI12-0445-1}
If a
loop_statement
with the
procedural_iterator
as its
iteration_scheme
(see
5.5) does not begin with the reserved
word
parallel, it is a bounded error if the loop body procedure
is invoked from a different logical thread of control than the one that
initiates the
loop_statement.
If detected, Program_Error is raised; otherwise, conflicts associated
with concurrent executions of the loop body procedure can occur without
being detected by the applicable conflict check policy (see
9.10.1).
Furthermore, propagating an exception or making an attempt to exit in
the presence of multiple threads of control will not necessarily terminate
the
loop_statement,
deadlock can occur, or the loop body procedure can be called again.
Discussion: {
AI12-0326-2}
Other Ada rules are still in effect for the allows exit subprogram
A,
of course. For instance, if a transfer of control causes finalization
which raises an exception, Program_Error will be propagated by
A
(rather than the transfer of control). In such a case, the bounded error
above would still apply. Another example is the case where an unrelated
task is waiting on the normal completion of the loop body procedure call
in
A. Such a task might end up waiting forever if a transfer of
control happens (this is a deadlock situation). This case does not require
additional wording, as the same thing would happen if an exception is
propagated from the loop body procedure or if
A executed a transfer
of control (such as a return statement).
Examples
for (C : Cursor) of My_Map.Iterate loop
Put_Line (My_Key_Type'Image (Key (C)) & " => " &
My_Element_Type'Image (Element (C)));
end loop;
-- The above is equivalent to:
declare
procedure P (C : Cursor) is
begin
Put_Line (My_Key_Type'Image (Key (c)) & " => " &
My_Element_Type'Image (Element (C)));
end P;
begin
My_Map.Iterate (P'Access);
end;
for (Name, Val) of Ada.Environment_Variables.Iterate(<>) loop
-- "(<>)" is optional because it is the last parameter
Put_Line (Name & " => " & Val);
end loop;
-- The above is equivalent to:
declare
procedure P (Name : String; Val : String) is
begin
Put_Line (Name & " => " & Val);
end P;
begin
Ada.Environment_Variables.Iterate (P'Access);
end;
Extensions to Ada 2012
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
