CVS difference for ai12s/ai12-0189-1.txt
--- ai12s/ai12-0189-1.txt 2018/03/30 07:55:08 1.10
+++ ai12s/ai12-0189-1.txt 2018/07/07 04:02:49 1.11
@@ -1,6 +1,8 @@
-!standard 5.5(3/3) 18-03-24 AI12-0189-1/05
+!standard 5.5(3/3) 18-07-06 AI12-0189-1/06
!standard 5.5.3(0)
!class Amendment 16-06-02
+!status Amendment 1-2012 18-07-06
+!status ARG Approved 5-0-2 18-06-24
!status work item 16-06-02
!status received 16-05-06
!priority Medium
@@ -90,10 +92,10 @@
of control out of the loop-body procedure. Possibilities include the
mechanism used to implement asynchronous transfer of control (ATC), an
unhandleable exception, or some more direct use of the implementation's
-finalization mechanism. One important simplification is that this
+finalization mechanism. One important simplification is that this
transfer of control is not signaled by a separate task, but is rather
caused by an action in the task executing the body designated by the
-access-to-procedure value. That could presumably make it simpler and
+access-to-procedure value. That could presumably make it simpler and
safer than ATC.
If we presume this is implemented using an exception-like thing which
@@ -185,7 +187,8 @@
iterator_actual_parameter_part ::=
(iterator_parameter_association {, iterator_parameter_association})
- iterator_parameter_association ::= parameter_association
+ iterator_parameter_association ::=
+ parameter_association
| parameter_association_with_box
parameter_association_with_box ::=
@@ -244,13 +247,23 @@
type:
Allows_Exit
- The Allows_Exit aspect is of type Boolean. The specified value shall
- be static. The Allows_Exit of an inherited primitive subprogram is
+ The Allows_Exit aspect is of type Boolean. The specified value shall
+ be static. The Allows_Exit 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
+ overrides. If not specified or inherited as True, the Allows_Exit
aspect of a subprogram or entry is False.
+ Specifying the Allows_Exit aspect True for a subprogram asserts that the
+ subprogram is prepared to be completed by arbitrary transfers of control
+ from the subprogram represented by the access-to-subprogram value
+ Redundant[, including propagation of exceptions. A subprogram for which
+ Allows_Exit is True should use finalization for any necessary cleanup, and
+ in particular should not use exception handling to implement cleanup].
+
+ AARM Ramification: A subprogram that does not need cleanup meets the
+ assertion, and thus can specify Allows_Exit to True.
+
Legality Rules
If a subprogram or entry overrides an inherited dispatching subprogram
@@ -260,15 +273,9 @@
The sequence_of_statements of a loop_statement with a
procedural_iterator as its iteration_scheme shall contain an
exit_statement, return statement, goto_statement, or requeue_statement
-that leaves the loop only if the callable entity C has an Allows_Exit
-aspect specified True.
+that leaves the loop only if the callable entity C associated with the
+procedural_iterator has an Allows_Exit aspect specified True.
-The sequence_of_statements of a loop_statement with a
-procedural_iterator as its iteration_scheme shall contain an
-exit_statement, return statement, goto_statement, or requeue_statement
-that leaves the loop only if the callable entity C has an Allows_Exit
-aspect specified True.
-
Examples
Example of iterating over a map from My_Key_Type to My_Element_Type (see
@@ -291,7 +298,7 @@
My_Map.Iterator (P'Access);
end;
-Example of iterating over the environment variables (see A.17)
+Example of iterating over the environment variables (see A.17):
for (Name, Val) of Ada.Environment_Variables.Iterate(<>) loop
-- "(<>)" is optional because it is the last parameter
@@ -310,18 +317,10 @@
end;
!discussion
-
-This proposal is more general than the proposals in AI12-0009-1 and
-AI12-0188-1. If adopted, those AIs should be killed (given No Action status).
-
-Here is an example of iterating over the environment variables:
- for (Name, Val) of Ada.Environment_Variables.Iterate(<>) loop
- -- or "Ada_Environment_Variables.Iterate" since "<>" is last param
-
- Put_Line (Name & " => " & Val);
-
- end loop;
+This proposal is more general than the proposals in AI12-0009-1 and
+AI12-0188-1, as shown by the examples above. If adopted, those AIs should be
+killed (given No Action status). [Editor's note: This happened.]
We could add iterators to appropriate Container types that took an
access-to-procedure with two parameters, namely Key and Value, to produce
@@ -392,6 +391,175 @@
for the parallel block construct, then this might be an alternative worth
considering, as it eliminates the implication that a loop is being performed
(unless you are from the Fortran world where "do" means "loop" ;-).
+
+!corrigendum 5.5(3/3)
+
+@drepl
+@xcode<@fa<iteration_scheme> ::= @ft<@b<while>> @fa<condition>
+ | @ft<@b<for>> @fa<loop_parameter_specification>
+ | @ft<@b<for>> @fa<iterator_specification>>
+@dby
+@xcode<@fa<iteration_scheme> ::= @ft<@b<while>> @fa<condition>
+ | @ft<@b<for>> @fa<loop_parameter_specification>
+ | @ft<@b<for>> @fa<iterator_specification>
+ | @ft<@b<for>> @fa<procedural_iterator>>
+
+!corrigendum 5.5.3(0)
+
+@dinsc
+
+A @fa<procedural_iterator> invokes a user-defined procedure, passing in the body of
+the enclosing @fa<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.
+
+@s8<@i<Syntax>>
+
+@xcode<@fa<procedural_iterator> ::=
+ @fa<iterator_parameter_specification> @ft<@b<of>> @fa<iterator_procedure_call>>
+
+@xcode<@fa<iterator_parameter_specification> ::=
+ @fa<formal_part>
+ | (@fa<identifier>{, @fa<identifier>})>
+
+@xcode<@fa<iterator_procedure_call> ::=
+ @fa<@i<procedure_>name>
+ | @fa<@i<procedure_>prefix> @fa<iterator_actual_parameter_part>>
+
+@xcode<@fa<iterator_actual_parameter_part> ::=
+ (@fa<iterator_parameter_association> {, @fa<iterator_parameter_association>})>
+
+@xcode<@fa<iterator_parameter_association> ::=
+ @fa<parameter_association>
+ | @fa<parameter_association_with_box>>
+
+@xcode<@fa<parameter_association_with_box> ::=
+ [ @fa<@i<formal_parameter_>selector_name> =@> ] <@>>
+
+At most one @fa<iterator_parameter_association> within an
+@fa<iterator_actual_parameter_part> shall be a
+@fa<parameter_association_with_box>.
+
+@s8<@i<Name Resolution Rules>>
+
+The @fa<name> or @fa<prefix> given in an @fa<iterator_procedure_call> shall resolve to
+denote a callable entity @i<C> that is a procedure, or an entry renamed as
+(viewed as) a procedure. The @fa<name> or @fa<prefix> shall not resolve to denote
+an abstract subprogram unless it is also a dispatching subprogram.
+When there is an @fa<iterator_actual_parameter_part>, the @fa<prefix>
+can be an @fa<implicit_dereference> of an access-to-subprogram value.
+
+An @fa<iterator_procedure_call> without a @fa<parameter_association_with_box>
+is equivalent to one with an @fa<iterator_actual_parameter_part> with an
+additional @fa<parameter_association_with_box> at the end, with the
+@i<formal_parameter_>@fa<selector_name> identifying the last formal parameter of
+the callable entity denoted by the @fa<name> or @fa<prefix>.
+
+An @fa<iterator_procedure_call> shall contain at most one
+@fa<iterator_parameter_association> for each formal parameter of the callable
+entity @i<C>. Each formal parameter without an
+@fa<iterator_parameter_association> shall have a @fa<default_expression> (in
+the profile of the view of @i<C> denoted by the @fa<name> or @fa<prefix>). This
+rule is an overloading rule (see 8.6).
+
+The formal parameter of the callable entity @i<C> associated with the
+@fa<parameter_association_with_box> shall be of an anonymous
+access-to-procedure type @i<A>.
+
+@s8<@i<Legality Rules>>
+
+The anonymous access-to-procedure type @i<A> shall have at least one formal
+parameter in its parameter profile. If the @fa<iterator_parameter_specification>
+is a @fa<formal_part>, then this @fa<formal_part> shall be mode conformant
+with that of @i<A>. If the @fa<iterator_parameter_specification> is a list of
+@fa<identifier>s, the number of formal parameters of @i<A> shall be the same as the
+length of this list.
+
+@s8<@i<Static Semantics>>
+
+A @fa<loop_statement> with an @fa<iteration_scheme> that has a
+@fa<procedural_iterator> is equivalent to a local declaration of a procedure P
+followed by a @fa<procedure_call_statement> that is formed from the
+@fa<iterator_procedure_call> by replacing the <@> of the
+@fa<parameter_association_with_box> with P'Access.
+The @fa<formal_part> of the locally declared procedure P is formed from the
+@fa<formal_part> of the anonymous access-to-procedure type @i<A>, by replacing
+the @fa<identifier> of each formal parameter of this @fa<formal_part> with the
+@fa<identifier> of the corresponding formal parameter or element of the list
+of @fa<identifier>s given in the @fa<iterator_parameter_specification>.
+
+The following aspect may be specified for a subprogram or entry S that
+has at least one formal parameter of an anonymous access-to-subprogram
+type:
+
+@xhang<@xterm<Allows_Exit>
+The Allows_Exit aspect is of type Boolean. The specified value shall
+be static. The Allows_Exit 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 subprogram or entry is False.>
+
+@xindent<Specifying the Allows_Exit aspect True for a subprogram asserts
+that the subprogram is prepared to be completed by arbitrary transfers of
+control from the subprogram represented by the access-to-subprogram value,
+including propagation of exceptions. A subprogram for which
+Allows_Exit is True should use finalization for any necessary cleanup, and
+in particular should not use exception handling to implement cleanup.>
+
+@s8<@i<Legality Rules>>
+
+If a subprogram or entry overrides an inherited dispatching subprogram
+that has a True Allows_Exit aspect, only a confirming specification of
+True is permitted for the aspect on the overriding declaration.
+
+The @fa<sequence_of_statements> of a @fa<loop_statement> with a
+@fa<procedural_iterator> as its @fa<iteration_scheme> shall contain an
+@fa<exit_statement>, return statement, @fa<goto_statement>, or
+@fa<requeue_statement> that leaves the loop only if the callable entity @i<C>
+associated with the @fa<procedural_iterator> has an Allows_Exit
+aspect specified True.
+
+@s8<@i<Examples>>
+
+Example of iterating over a map from My_Key_Type to My_Element_Type (see
+A.18.4):
+
+@xcode<@b<for> (C : Cursor) @b<of> My_Map.Iterate @b<loop>
+ Put_Line (My_Key_Type'Image (Key (C)) & " =@> " &
+ My_Element_Type'Image (Element (C)));
+@b<end loop>;>
+
+@xcode<--@ft<@i< The above is equivalent to:>>>
+
+@xcode<@b<declare>
+ @b<procedure> P (C : Cursor) @b<is>
+ @b<begin>
+ Put_Line (My_Key_Type'Image (Key (c)) & " =@> " &
+ My_Element_Type'Image (Element (C)));
+ @b<end> P;
+@b<begin>
+ My_Map.Iterator (P'Access);
+@b<end>;>
+
+Example of iterating over the environment variables (see A.17):
+
+@xcode<@b<for> (Name, Val) @b<of> Ada.Environment_Variables.Iterate(<@>) @b<loop>
+ --@ft<@i< "(<@>)" is optional because it is the last parameter>>
+ Put_Line (Name & " =@> " & Val);
+@b<end loop>;>
+
+@xcode<--@ft<@i< The above is equivalent to:>>>
+
+@xcode<@b<declare>
+ @b<procedure> P (Name : String; Val : String) @b<is>
+ @b<begin>
+ Put_Line (Name & " =@> " & Val);
+ @b<end> P;
+@b<begin>
+ Ada.Environment_Variables.Iterate (P'Access);
+@b<end>;>
+
!ASIS
Questions? Ask the ACAA Technical Agent