CVS difference for ai12s/ai12-0189-1.txt

Differences between 1.10 and version 1.11
Log of other versions for file 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