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

Differences between 1.11 and version 1.12
Log of other versions for file ai12s/ai12-0189-1.txt

--- ai12s/ai12-0189-1.txt	2018/07/07 04:02:49	1.11
+++ ai12s/ai12-0189-1.txt	2018/07/15 00:22:52	1.12
@@ -395,11 +395,11 @@
 !corrigendum 5.5(3/3)
-@xcode<@fa<iteration_scheme> ::= @ft<@b<while>> @fa<condition>
+@xcode<@fa<iteration_scheme>@fa< ::= >@ft<@b<while>> @fa<condition>
    | @ft<@b<for>> @fa<loop_parameter_specification>
    | @ft<@b<for>> @fa<iterator_specification>>
-@xcode<@fa<iteration_scheme> ::= @ft<@b<while>> @fa<condition>
+@xcode<@fa<iteration_scheme>@fa< ::= >@ft<@b<while>> @fa<condition>
    | @ft<@b<for>> @fa<loop_parameter_specification>
    | @ft<@b<for>> @fa<iterator_specification>
    | @ft<@b<for>> @fa<procedural_iterator>>
@@ -415,26 +415,26 @@
-@xcode<@fa<procedural_iterator> ::=
+@xcode<@fa<procedural_iterator>@fa< ::= >
      @fa<iterator_parameter_specification> @ft<@b<of>> @fa<iterator_procedure_call>>
-@xcode<@fa<iterator_parameter_specification> ::=
+@xcode<@fa<iterator_parameter_specification>@fa< ::= >
    | (@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_procedure_call>@fa< ::= >
+     @ft<@i<procedure_>>@fa<name>
+   | @ft<@i<procedure_>>@fa<prefix> @fa<iterator_actual_parameter_part>>
-@xcode<@fa<iterator_actual_parameter_part> ::=
+@xcode<@fa<iterator_actual_parameter_part>@fa< ::= >
     (@fa<iterator_parameter_association> {, @fa<iterator_parameter_association>})>
-@xcode<@fa<iterator_parameter_association> ::=
+@xcode<@fa<iterator_parameter_association>@fa< ::= >
    | @fa<parameter_association_with_box>>
-@xcode<@fa<parameter_association_with_box> ::=
-   [ @fa<@i<formal_parameter_>selector_name> =@> ] <@>>
+@xcode<@fa<parameter_association_with_box>@fa< ::= >
+   [ @ft<@i<formal_parameter_>>@fa<selector_name> =@> ] <@>>
 At most one @fa<iterator_parameter_association> within an
 @fa<iterator_actual_parameter_part> shall be a 
@@ -2224,5 +2224,60 @@
 Here is a modest update to the "loop-body" procedure proposal, consistent with
 the minutes from our last discussion of the AI. [This is version /05 of the
 AI - ED]
+From: Randy Brukardt
+Sent: Friday, July 6, 2018  4:03 PM
+Another issue, this time with the definition of the Allows_Exit aspect:
+nothing in the proposed Standard wording ever explains what it is for! The 
+!proposal talks about that extensively, but there's nothing in the wording.
+So the programmer has no idea (unless they read the AI) when they should be
+applying it to a subprogram or what that implies about the implementation of
+that subprogram.
+The existing wording is purely mechanical:
+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
+   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.
+I suggest that we add another paragraph after this, something like:
+   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.
+The second sentence of this new paragraph might have been a Note or 
+Implementation Advice, but it seemed necessary to grok the concept, and thus 
+I put it into the normative wording (marked as Redundant).
+I considered the idea of putting the Implementation Note (found in the 
+!proposal section) into the AARM, but it seems too large for that. And it 
+defies simplification. So I didn't do that.
+Thoughts? Suggestions? Improvements? Brick-bats?
+From: Tullio Vardanega
+Sent: Saturday, July 7, 2018  9:11 AM
+The additional paragraph looks good to me.

Questions? Ask the ACAA Technical Agent