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!
+
+****************************************************************
Questions? Ask the ACAA Technical Agent