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

--- ai12s/ai12-0212-1.txt	2019/01/25 08:38:51	1.21
+++ ai12s/ai12-0212-1.txt	2019/01/28 00:20:42	1.22
@@ -1,4 +1,4 @@
-!standard 4.3.5(0)                                  19-01-11  AI12-0212-1/09
+!standard 4.3.5(0)                                  19-01-27  AI12-0212-1/10
 !standard 1.1.4(12)
 !standard 1.1.4(13)
 !standard 2.1(15)
@@ -480,7 +480,7 @@
 
     The name specified for Empty shall denote a constant of type T,
     or denote a function with a result type of T that has no parameters,
-    or that has one IN parameter of type Integer with a default expression.
+    or that has one IN parameter of type Integer.
       AARM Reason: In the function case, the parameter, if present,
       may be used to specify an initial size for the container, in
       anticipation of adding elements to it. For a positional
@@ -646,6 +646,12 @@
         container_element_associations;
       * otherwise, to an implementation-defined value.
 
+        AARM Implementation Note:
+         This value ought to be an estimate for the number of
+         elements in the aggregate, if one is available. If not,
+         it is suggested to use the default value for the parameter
+         if one exists, and zero otherwise.
+
 The evaluation then proceeds as follows:
   * for a null_container_aggregate, the anonymous object A is the result;
   * for a positional_container_aggregate of a type with a specified
@@ -690,15 +696,16 @@
      expression, the corresponding call on Assign_Indexed is not
      performed, leaving the component as it was upon return from
      the New_Indexed function;
-   * for any other named_container_aggregate, the
-     container_element_associations (which are necessarily
-     iterated_element_associations) are evaluated in the order given:
-       * the iterated_element_association is elaborated, then an iteration
-         is performed as described in 5.5 or 5.5.2, and for each value 
-         of the loop parameter of the
-         iteration, the Add_Unnamed procedure is invoked, with the
-         anonymous object A as the first parameter and the result of
-         evaluating the expression as the second parameter.
+   * for any other named_container_aggregate, the 
+     container_element_associations (which are necessarily 
+     iterated_element_associations) are evaluated in the 
+     order given; each such evaluation comprises two steps:
+       1. the iterated_element_association is elaborated;
+       2. an iteration is performed as described in 5.5 or 5.5.2, 
+          and for each value of the loop parameter of the
+          iteration, the Add_Unnamed procedure is invoked, with the
+          anonymous object A as the first parameter and the result of
+          evaluating the expression as the second parameter.
            AARM Ramification: In this case, the value of the loop parameter
            is not directly relevant, though presumably it appears within
            the expression of the iterated_element_association.
@@ -1316,7 +1323,7 @@
 
 The @fa<name> specified for Empty shall denote a constant of type @i<T>,
 or denote a function with a result type of @i<T> that has no parameters,
-or that has one @b<in> parameter of type Integer with a default expression.
+or that has one @b<in> parameter of type Integer.
 
 The @i<procedure_>@fa<name> specified for Add_Unnamed, if any, shall
 denote a procedure that has two parameters, the first an @b<in out>
@@ -1528,14 +1535,16 @@
 
 @xbullet<for any other @fa<named_container_aggregate>, the
 @fa<container_element_association>s (which are necessarily
-@fa<iterated_element_association>s) are evaluated in the order given:>
+@fa<iterated_element_association>s) are evaluated in the order given; each 
+such evaluation comprises two steps:>
 
-@xinbull<the @fa<iterated_element_association> is elaborated, then an 
-iteration is performed as described in 5.5 or 5.5.2, and for each value 
-of the loop parameter of the iteration, the Add_Unnamed procedure is invoked, 
-with the anonymous object @i<A> as the first parameter and the result of
-evaluating the @fa<expression> as the second parameter.>
+@xindent<@xhang<@xterms<1.>the @fa<iterated_element_association> is elaborated;>>
 
+@xindent<@xhang<@xterms<2.>an iteration is performed as described in 5.5 or 5.5.2, 
+and for each value of the loop parameter of the iteration, the Add_Unnamed 
+procedure is invoked, with the anonymous object @i<A> as the first parameter 
+and the result of evaluating the @fa<expression> as the second parameter.>>
+
 @s8<@i<Examples>>
 
 Declarations of Set_Type, Map_Type, and Vector_Type:
@@ -4691,3 +4700,171 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Sent: Thursday, January 24, 2019  7:39 PM
+
+Toward the end of the Dynamic Semantics, we have:
+
+   * for any other named_container_aggregate, the
+     container_element_associations (which are necessarily
+     iterated_element_associations) are evaluated in the order given:
+       * the iterated_element_association is elaborated, then an iteration
+         is performed as described in 5.5 or 5.5.2, and for each value 
+         of the loop parameter of the
+         iteration, the Add_Unnamed procedure is invoked, with the
+         anonymous object A as the first parameter and the result of
+         evaluating the expression as the second parameter.
+
+Note that there is only one indented bullet here (there are plenty of the 
+outer bullets). The ISO drafting rules don't allow such things, and it doesn't 
+make a ton of sense in the first place.
+
+Is there some way to rewrite this so that it makes sense either as multiple 
+subbullets or no subbullets at all? My best attempts are something like:
+
+   * for any other named_container_aggregate, the container_element_associations 
+     (which are necessarily iterated_element_associations) are evaluated in the 
+     order given; for each such association:
+       * the iterated_element_association is first elaborated;
+       * then an iteration is performed as described in 5.5 or 5.5.2, 
+         and for each value of the loop parameter of the
+         iteration, the Add_Unnamed procedure is invoked, with the
+         anonymous object A as the first parameter and the result of
+         evaluating the expression as the second parameter.
+
+Or
+
+   * for any other named_container_aggregate, the
+     container_element_associations (which are necessarily
+     iterated_element_associations) are evaluated in the order given;
+     for each such association, the iterated_element_association is elaborated, 
+     then an iteration is performed as described in 5.5 or 5.5.2, and for 
+     each value of the loop parameter of the iteration, the Add_Unnamed 
+     procedure is invoked, with the anonymous object A as the first parameter 
+     and the result of evaluating the expression as the second parameter.
+
+The latter is a bit of a run-on paragraph, and the former is ordering bullets 
+(which we're really not supposed to do, either, although we do it often). 
+Note: I didn't put any periods in the text as the entire block is written 
+without any. Just doing that in one bullet would be unusual.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 26, 2019  6:22 PM
+
+How about this slight rewording of your first attempt:
+
+  * for any other named_container_aggregate, 
+    the container_element_associations 
+    (which are necessarily iterated_element_associations) 
+    are evaluated in the 
+    order given; each such evaluation comprises two steps:
+      1. the iterated_element_association is elaborated;
+      2. an iteration is performed as described in 5.5 or 5.5.2, 
+          and for each value of the loop parameter of the
+          iteration, the Add_Unnamed procedure is invoked, with the
+          anonymous object A as the first parameter and the result of
+          evaluating the expression as the second parameter.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 27, 2019  3:48 PM
+
+Love it! I'll use that as your Editorial Review comment on this AI (so we 
+don't have to see this again).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 24, 2019  7:47 PM
+
+The rules for setting the actual parameter to a call of the Empty function 
+for a container_aggregate end with:
+
+ * otherwise, to an implementation-defined value.
+
+The requirements for the Empty function are:
+
+   ... or denote a function with a result type of @i<T> that has no parameters,
+   or that has one @b<in> parameter of type Integer with a default expression.
+
+So we've required the function to have a default expression, but nowhere do 
+we ever use that default for anything.
+
+So, it seems to me that we should either drop the requirement for a default 
+expression, or use the default expression in the "otherwise" case.
+
+I'm not sure which is better, so I ask for thoughts. (Dropping the requirement 
+is probably a bit less change and bit easier for me, but that's hardly a 
+reason to do something.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 26, 2019  6:33 PM
+
+...
+> So, it seems to me that we should either drop the requirement for a 
+> default expression, or use the default expression in the "otherwise" case.
+
+I believe the original intent was that simple-minded implementations would 
+use the default, while more sophisticated implementations might try to 
+estimate the number of elements.  But you are right that that is pretty hard 
+to enforce!  Perhaps drop the requirement, but add the following 
+implementation advice:
+
+    Implementation Advice
+       The implementation-defined value supplied to an Empty function 
+       with one formal parameter should use the default for that parameter, 
+       if any, in the absence of an estimate for the number of
+       elements in the aggregate.  If there is no default, the implementation 
+       should use zero when it has no estimate.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 27, 2019  3:57 PM
+
+Humm. I suppose I can process dropping the requirement as an Editorial Review 
+comment (getting rid of unused rules seems to qualify). Can't add an ImplAdv 
+that way, though.
+
+In any case, this ImplAdv seems like overkill to me. It's a lot of words that 
+say "do something reasonable". Perhaps this would make more sense as an AARM 
+Implementation Note, which we could place directly after the "otherwise, to an
+implementation-defined value" (so we don't need all of the setup text).
+
+   AARM Implementation Note:
+       This value ought to be an estimate for the number of
+       elements in the aggregate, if one is available. If not,
+       it is suggested to use the default value for the parameter
+       if one exists, and zero otherwise.
+
+P.S. We have a combined Winter Storm Warning (6-10 inches) and Wind-Chill 
+Warning (-35F) for tomorrow, so I'm working a half day today in hopes of not
+totally losing the work day. (And am doing today's wash tomorrow, so I won't
+come in until late regardless of what the weather does.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, January 27, 2019  5:22 PM
+
+>AARM Implementation Note:
+>      This value ought to be an estimate for the number of
+>      elements in the aggregate, if one is available. If not,
+>      it is suggested to use the default value for the parameter
+>      if one exists, and zero otherwise.
+
+Works for me!
+
+>P.S. We have a combined Winter Storm Warning (6-10 inches) and Wind-Chill
+>Warning (-35F) for tomorrow, so I'm working a half day today in hopes of not
+>totally losing the work day. (And am doing today's wash tomorrow, so I won't
+>come in until late regardless of what the weather does.)
+
+Brrrrrrrrrr!
+
+****************************************************************