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

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

--- ai12s/ai12-0242-1.txt	2018/10/16 01:08:51	1.11
+++ ai12s/ai12-0242-1.txt	2018/10/17 02:55:02	1.12
@@ -1,4 +1,4 @@
-!standard 4.5.9 (0)                                18-10-15    AI12-0242-1/05
+!standard 4.5.9 (0)                                18-10-16    AI12-0242-1/06
 !class Amendment 14-06-20
 !status work item 14-06-20
 !status received 14-06-17
@@ -173,13 +173,14 @@
 
 !wording
 
-Add after 4.9(8)
-
-"a reduction_expression whose prefix statically denotes a statically
-constrained array object or array subtype, and whose attribute_designator
-is Reduce, and whose reducer_subprogram denotes a static functions;"
+Replace 4.1.4(3/2):
+ 
+attribute_designator ::=
+    identifier[(static_expression)]
+  | identifier(reduction_specification)
+  | Access | Delta | Digits | Mod
 
-Add New subclause
+Add a new subclause 4.5.9:
 
 4.5.9 Reduction Expressions
 
@@ -198,13 +199,16 @@
 
 Name Resolution Rules
 
-The expected type of a reduction expression is any nonlimited type.
+The expected type of a reduction expression shall be a single nonlimited 
+type R.
 
+AARM TO BE Honest: R is really a subtype, and we call it that below, but it 
+gets confusing to call the "expected type" a subtype.
+
 For a subtype S of a component of an array type A or element of an
 iterable container object C and a corresponding object O of the
 array or iterable container object, which is denoted
-by the prefix of a reduction_expression, and a subtype R where R is the
-expected type of the reduction_expression;
+by the prefix of a reduction_expression:
 
 A /reducer_/subprogram either denotes a function with the following
 specification:
@@ -7915,5 +7919,141 @@
 I also added cross-references to other AIs the !proposal and !discussion,
 removed some extra spaces, added missing periods, broke up a couple of overlong
 lines.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 15, 2018  8:29 PM
+
+> This minutes say "Steve wonders if we would ever want a 'Reduce to be 
+> static. We'll leave that for the AI author.". I think a better answer 
+> here would have been "no". :-)
+
+I would agree with Randy here -- static expressions are important in some 
+contexts, such as the choices in a case statement, or the string argument 
+of a pragma Export (for example).  In other cases, compile-time evaluation
+without being officially static is fine, and that's all we would ever hope
+for here, as far as I am concerned, and compile-time evaluation is purely an
+optimization, so not something we need to talk about in the standard.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Tuesday, October 16, 2018  9:06 PM
 
-*****************************************************************
+> Brad writes:
+>>    - Reduction expressions may be static expressions for the 'Reduce 
+>> case, if the reducer_subprogram denotes a static function.
+>>
+> and in the AI:
+>>
+>>Add after 4.9(8)
+>>
+>>"a reduction_expression whose prefix statically denotes a statically 
+>>constrained array object or array subtype, and whose 
+>>attribute_designator is Reduce, and whose reducer_subprogram denotes a 
+>>static functions;"
+> 
+> Umm, this doesn't require the components of the prefix to be static. 
+> That seems rather fundamental to the definition of a static 
+> expression! Also, Ada currently doesn't have any static composite 
+> types other than strings; I have to wonder the wisdom of introducing 
+> them by a single special case, rather than some larger generalization 
+> of static expressions. (Static strings, after all are a hack to 
+> support interfacing.)
+> 
+> This minutes say "Steve wonders if we would ever want a 'Reduce to be 
+> static. We'll leave that for the AI author.". I think a better answer 
+> here would have been "no". :-)
+
+Fine by me. It was sort of a Hail-Mary pass into the static end-zone to see if
+my receiver Steve could catch it. Looks like the pass was intercepted, (or 
+more likely, I fumbled it).
+
+> ----
+> 
+>>Syntax
+>>
+>>reduction_specification ::= /reducer_/name, 
+>>/initial_value_/expression[,
+> ...
+>>
+>>A /Reduction Expression/ is an attribute reference where the 
+>>identifier of the attribute_reference is Reduce or Parallel_Reduce and 
+>>the expression of the attribute_designator is a reduction_specification.
+> 
+> A reduction_specification is not an expression, so the above 
+> description is nonsense. You need to define this completely if you are 
+> going to do any of it this way:
+> 
+> Replace 4.1.4(3/2):
+> 
+> attribute_designator ::=
+>    identifier[(static_expression)]
+>  | identifier(reduction_specification)
+>  | Access | Delta | Digits | Mod
+> 
+> [Note: I just made Steve do that same thing with his AI12-0243-1.]
+
+Ok Thanks!
+
+> ----
+> 
+>>The expected type of a reduction expression is any nonlimited type.
+> 
+> This is fine, but then you say "R" is the expected type of the 
+> reduction expression -- but you just said that that is any nonlimited 
+> type. Can't have it both ways in a single set of Name Resolution 
+> Rules. Somewhere, "R" needs to be a single specific type (or whatever it is 
+> restricted to).
+
+I'm not sure I understand this comment, but what I am trying to say is that 
+"R" is of the same type as the expected type of the expression. That is, 
+first the expected type is resolved, (based on context) then once you know 
+that, you can resolve the reduction_expression.
+
+Or perhaps I should say that "R" is of any nonlimited type, and then say that
+the expected type of a reduction expression is the type or "R"? Or am I still
+missing something?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, October 16, 2018  9:46 PM
+
+> I'm not sure I understand this comment, but what I am trying to say is 
+> that "R" is of the same type as the expected type of the expression. 
+> That is, first the expected type is resolved, (based on context) then 
+> once you know that, you can resolve the reduction_expression.
+> 
+> Or perhaps I should say that "R" is of any nonlimited type, and then 
+> say that the expected type of a reduction expression is the type or 
+> "R"? Or am I still missing something?
+
+All of the rules of type resolution are applied simultaneously (unless 
+otherwise defined). So you can't have conflicting rules or rules that need
+an order unless you say that.
+
+I presume you want this to resolve like an aggregate (don't look inside until 
+the outside is figured out). If you look at those rules, they all say that 
+the type has to be a single type. Probably that's all you need to do here:
+
+   The expected type of a reduction expression shall be a single nonlimited type.
+
+You need "single" so that nothing from the "inside" of the reduction can 
+affect the outside. Otherwise, if you had two possible types A and B, one 
+would have to try both as R and if exactly one worked, that would resolve.
+As noted above you don't want that.
+
+You might as well define the R here too:
+
+   The expected type of a reduction expression shall be a single nonlimited 
+   type R.
+
+and then you can drop the other part defining that name. (Then there's no 
+apparent conflict.)
+
+I'll just make this change with the others from your message unless you tell 
+me not to.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent