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

Differences between 1.22 and version 1.23
Log of other versions for file ai12s/ai12-0212-1.txt

--- ai12s/ai12-0212-1.txt	2019/01/28 00:20:42	1.22
+++ ai12s/ai12-0212-1.txt	2019/01/29 23:56:48	1.23
@@ -456,7 +456,7 @@
 The Aggregate aspect of the type of the aggregate determines how the
 elements are combined to form the container.
 
-Given a type T other than an array type, the following type-related
+For a type other than an array type, the following type-related
 operational aspect may be specified:
 
   Aggregate
@@ -468,18 +468,18 @@
        New_Indexed => /function_/name,
        Assign_Indexed => /procedure_/name])
 
+    The type for which this aspect is specified is known as the
+    /container type/ of the Aggregate aspect. 
     A /procedure_/name shall be specified for at least one of Add_Named,
     Add_Unnamed, or Assign_Indexed. If Add_Named is specified, neither
     Add_Unnamed nor Assign_Indexed shall be specified. Either both or
-    neither of New_Indexed and Assign_Indexed shall be specified. If the
-    associated type T is a private type, the full type shall not be an
-    array type. If type T is limited, the name specified for Empty
-    shall denote a function rather than a constant object.
+    neither of New_Indexed and Assign_Indexed shall be specified.
 
 Name Resolution Rules
 
-    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,
+    The name specified for Empty for an Aggregate aspect shall denote a 
+    constant of the container type, or denote a function with a result type 
+    of the container type that has no parameters,
     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
@@ -490,28 +490,38 @@
       to estimate the number of elements that the iterator will produce,
       but it is not required to do so.
 
-    The /procedure_/name specified for Add_Unnamed, if any, shall
-    denote a procedure that has two parameters, the first an IN OUT
-    parameter of type T, and the second an IN parameter of some
-    nonlimited type, called the /element type/ of T.
-
-    The /function_/name specified for New_Indexed, if any, shall denote
-    a function with a result type of T, and two parameters of the same
-    discrete type, with that type being the /key type/ of the container.
+    The /procedure_/name specified for Add_Unnamed for an Aggregate aspect,
+    shall denote a procedure that has two parameters, the first an IN OUT
+    parameter of the container type, and the second an IN parameter of some
+    nonlimited type, called the /element type/ of the container type.
+
+    The /function_/name specified for New_Indexed for an Aggregate aspect
+    shall denote a function with a result type of the container type, and 
+    two parameters of the same
+    discrete type, with that type being the /key type/ of the container type.
       AARM Reason: The New_Indexed function is used instead of Empty
       as the first step of creating an aggregate that is initialized
       using the Assign_Indexed procedure.
 
-    The /procedure_/name specified for Add_Named or Assign_Indexed, if any,
-    shall denote a procedure that has three parameters, the first an IN
-    OUT parameter of type T, the second an IN parameter of a nonlimited
+    The /procedure_/name specified for Add_Named or Assign_Indexed for an 
+    Aggregate aspect shall denote a procedure that has three parameters, 
+    the first an IN
+    OUT parameter of the container type, the second an IN parameter of a nonlimited
     type (the /key type/ of the container), and the third,
     an IN parameter of a nonlimited type that is called the /element
-    type/ of T. In the case of Assign_Indexed, the key type shall be the
-    same type as that of the parameters of New_Indexed.
+    type/ of the container type.
+
+Legality Rules
 
-    If both Add_Unnamed and Assign_Indexed are specified, the final
-    parameters shall be of the same type -- the element type of T.
+    If the container type of an Aggregate aspect is a private type, the full 
+    type of the container type shall not be an array type. If container type is 
+    limited, the name specified for Empty shall denote a function rather than a 
+    constant object.
+
+    For an Aggregate aspect, the key type of Assign_Indexed shall be the same 
+    type as that of the parameters of New_Indexed. Additionally, if both 
+    Add_Unnamed and Assign_Indexed are specified, the final parameters shall 
+    be of the same type -- the element type of the container type.
 
 Static Semantics
 
@@ -1300,7 +1310,7 @@
 The Aggregate aspect of the type of the @fa<aggregate> determines how the
 elements are combined to form the container.
 
-Given a type @i<T> other than an array type, the following type-related
+For a type other than an array type, the following type-related
 operational aspect may be specified:
 
 @xhang<@xterm<Aggregate>This aspect is an @fa<aggregate> of the form:>
@@ -1311,39 +1321,50 @@
 @ @ @ @ New_Indexed =@> @i<function_>@fa<name>,@hr
 @ @ @ @ Assign_Indexed =@> @i<procedure_>@fa<name>])>
 
-@xindent<A @i<procedure_>@fa<name> shall be specified for at least one of 
+@xindent<The type for which this aspect is specified is known as the
+@i<container type> of the Aggregate aspect. 
+A @i<procedure_>@fa<name> shall be specified for at least one of 
 Add_Named, Add_Unnamed, or Assign_Indexed. If Add_Named is specified, neither
 Add_Unnamed nor Assign_Indexed shall be specified. Either both or
-neither of New_Indexed and Assign_Indexed shall be specified. If the
-associated type @i<T> is a private type, the full type shall not be an
-array type. If type @i<T> is limited, the name specified for Empty
-shall denote a function rather than a constant object.>
+neither of New_Indexed and Assign_Indexed shall be specified.>
 
 @s8<@i<Name Resolution Rules>>
 
-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,
+The @fa<name> specified for Empty for an Aggregate aspect shall denote a 
+constant of the container type, or denote a function with a result type 
+of the container type that has no parameters,
 or that has one @b<in> parameter of type Integer.
 
-The @i<procedure_>@fa<name> specified for Add_Unnamed, if any, shall
+The @i<procedure_>@fa<name> specified for Add_Unnamed for an Aggregate 
+aspect shall
 denote a procedure that has two parameters, the first an @b<in out>
-parameter of type @i<T>, and the second an @b<in> parameter of some
-nonlimited type, called the @i<element type> of @i<T>.
+parameter of the container type, and the second an @b<in> parameter of some
+nonlimited type, called the @i<element type> of the container type.
 
-The @i<function_>@fa<name> specified for New_Indexed, if any, shall denote
-a function with a result type of @i<T>, and two parameters of the same
-discrete type, with that type being the @i<key type> of the container.
+The @i<function_>@fa<name> specified for New_Indexed for an 
+Aggregate aspect shall denote
+a function with a result type of the container type, and two parameters of the 
+same discrete type, with that type being the @i<key type> of the container type.
 
-The @i<procedure_>@fa<name> specified for Add_Named or Assign_Indexed, if any,
+The @i<procedure_>@fa<name> specified for Add_Named or Assign_Indexed for an 
+Aggregate aspect 
 shall denote a procedure that has three parameters, the first an @b<in out>
-parameter of type @i<T>, the second an @b<in> parameter of a nonlimited type 
-(the @i<key type> of the container), and the third, an @b<in> parameter of a 
-nonlimited type that is called the @i<element type> of @i<T>. In the case of 
-Assign_Indexed, the key type shall be the same type as that of the parameters 
-of New_Indexed.
+parameter of the container type, the second an @b<in> parameter of a nonlimited 
+type (the @i<key type> of the container type), and the third, an @b<in> 
+parameter of a nonlimited type that is called the @i<element type> of the 
+container type.
 
-If both Add_Unnamed and Assign_Indexed are specified, the final
-parameters shall be of the same type @emdash the element type of @i<T>.
+@s8<@i<Legality Rules>>
+
+If the container type of an Aggregate aspect is a private type, the full 
+type of the container type shall not be an array type. If container type is 
+limited, the name specified for Empty shall denote a function rather than a 
+constant object.
+
+For an Aggregate aspect, the key type of Assign_Indexed shall be the same 
+type as that of the parameters of New_Indexed. Additionally, if both 
+Add_Unnamed and Assign_Indexed are specified, the final parameters shall 
+be of the same type @emdash the element type of the container type.
 
 @s8<@i<Static Semantics>>
 
@@ -4866,5 +4887,155 @@
 >come in until late regardless of what the weather does.)
 
 Brrrrrrrrrr!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 24, 2019  4:58 PM
+
+The resolution rules for the Aggregate aspect include:
+
+In the case of Assign_Indexed, the key type shall be the same type as that 
+of the parameters of New_Indexed.
+
+and 
+
+If both Add_Unnamed and Assign_Indexed are specified, the final parameters 
+shall be of the same type @emdash the element type of @i<T>.
+
+These two rules mean that one has to resolve all four subprogram names for the 
+Aggregate aspect as a group, rather than each individually. While that's 
+possible, it seems overly complicated and nothing like any other existing
+resolution. I would think it would make more sense to resolve each name 
+individually and then apply cross-item rules as Legality Rules. This is how 
+existing aspects work (although none use an aggregate template to specify all 
+of the names at once).
+
+This could make a difference if, say, both Add_Unnamed and Assign_Indexed are 
+specified and the given names are overloaded. For instance:
+     type Cont is ...
+         with Aggregate => Add_Unnamed => Append,
+                           Assign_Indexed => Replace_Element);
+
+     procedure Append (C : in out Cont; E : Element_Type);
+     procedure Append (C : in out Cont; X : Other_Type);
+     procedure Replace_Element (C : in out Cont; K : Key_Type; E : Element_Type);
+
+As resolution rules, the aspect would be legal, as Legality Rules, the aspect 
+would be illegal (as there would be no way to resolve the two Appends
+- they both have the required profile). In the latter case, one could always 
+use a rename to avoid the problem without adding an runtime cost.
+
+I note that there isn't a Legality Rules section for the aspect definition.
+There is a paragraph of rules in the primary aspect text that really ought 
+to be listed under Legality Rules as well:
+
+    A /procedure_/name shall be specified for at least one of Add_Named,
+    Add_Unnamed, or Assign_Indexed. If Add_Named is specified, neither
+    Add_Unnamed nor Assign_Indexed shall be specified. Either both or
+    neither of New_Indexed and Assign_Indexed shall be specified. If the
+    associated type T is a private type, the full type shall not be an
+    array type. If type T is limited, the name specified for Empty
+    shall denote a function rather than a constant object.
+
+Argubly the first part are more syntax rules which could reasonably stay with 
+the syntax definition (English-language syntax rules being a long tradition in
+the RM, and those are essentially the same as Legality Rules except that they
+are specifically about syntax. But the two rules about types really are 
+Legality Rules that have nothing to do with the syntax.
+
+So I'd suggest making a Legality Rules section that follows the Name 
+Resolution Rules:
+
+   Legality Rules
+
+    If the associated type T is a private type, the full type shall not be an
+    array type. If type T is limited, the name specified for Empty
+    shall denote a function rather than a constant object.
+
+    The key type of Assign_Indexed shall be the same type as that of the 
+    parameters of New_Indexed. If both Add_Unnamed and Assign_Indexed are specified,
+    the final parameters shall be of the same type -- the element type of T.
+
+I could make this change as an Editorial Review change, but I'd like some 
+feedback on whether it is important to use the unusually complex resolution
+rules for the aspect.
+
+Aside: "T" is used throughout the syntax, name resolution, and legality rules 
+for this section. This is highly unusual, especially once the rules in 
+question are in a different heading section in the RM. I wonder if we should 
+consider giving this type a name, say the "container type", and using that 
+rather than a "T" defined seven paragraphs prior. It would make the paragraphs 
+more wordy, but easier to understand when jumping into the middle of the 
+rules.
+
+That would look something like for the Legality Rules:
+
+    If the container type of the Aggregate aspect is a private type, the full 
+    type of the container type shall not be an array type. If container type is 
+    limited, the name specified for Empty shall denote a function rather than a 
+    constant object.
+
+    The key type of Assign_Indexed shall be the same type as that of the 
+    parameters of New_Indexed. If both Add_Unnamed and Assign_Indexed are specified,
+    the final parameters shall be of the same type -- the element type of the 
+    container type.
+
+Thoughts??
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 27, 2019  6:12 PM
+
+Any thoughts on the {above}? In the absence of comments, I'll probably write 
+something as part of a fix-up AI (I won't make a change this significant 
+unilaterally).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, January 27, 2019  7:02 PM
+
+> These two rules mean that one has to resolve all four subprogram 
+> names for the Aggregate aspect as a group, rather than each 
+> individually. While that's possible, it seems overly complicated and 
+> nothing like any other existing resolution. I would think it would 
+> make more sense to resolve each name individually and then apply 
+> cross-item rules as Legality Rules. This is how existing aspects work 
+> (although none use an aggregate template to specify all of the names 
+> at once).
+
+Agreed, that sounds better.  Introducing new kinds of name-resolution rules 
+is a pain for all.
+
+...
+> I could make this change as an Editorial Review change, but I'd like 
+> some feedback on whether it is important to use the unusually complex 
+> resolution rules for the aspect.
+
+No, simplify the resolution rules as you do this.
+
+> That would look something like for the Legality Rules:
+> 
+>    If the container type of the Aggregate aspect is a private type, 
+> the full
+>    type of the container type shall not be an array type. If 
+> container type is
+>    limited, the name specified for Empty shall denote a function 
+> rather than a
+>    constant object.
+> 
+>    The key type of Assign_Indexed shall be the same type as that of the
+>    parameters of New_Indexed. If both Add_Unnamed and Assign_Indexed 
+> are specified,
+>    the final parameters shall be of the same type -- the element type 
+> of the
+>    container type.
+> 
+> Thoughts??
+
+Agree, better to switch to "the container type" once you get too far from 
+the original aspect syntax.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent