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

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

--- ai12s/ai12-0190-1.txt	2019/01/09 06:41:00	1.11
+++ ai12s/ai12-0190-1.txt	2019/01/11 03:24:19	1.12
@@ -1,4 +1,4 @@
-!standard 4.4(7/3)                                  18-12-18  AI12-0190-1/07
+!standard 4.4(7/3)                                  19-01-10  AI12-0190-1/08
 !standard 4.5.9(0)
 !class Amendment 16-06-02
 !status Amendment 1-2012 18-12-10
@@ -58,6 +58,21 @@
 
 !wording
 
+modify 3.1(6/5):
+
+  Each of the following is defined to be a "declaration": any 
+  basic_declaration; an enumeration_literal_specification; a 
+  discriminant_specification; a component_declaration; an 
+  iterated_component_association; {a defining_identifier of a 
+  function_formal_parameter_list;} a loop_parameter_specification; an 
+  iterator_specification; a parameter_specification; a subprogram_body; 
+  an extended_return_object_declaration; an entry_declaration; 
+  an entry_index_specification; a choice_parameter_specification; 
+  a generic_formal_parameter_declaration.
+
+[Editor's note: These items are given in the order that they appear in the 
+Standard.]
+
 Replace 4.4(7/3) with:
 
   primary ::=
@@ -81,7 +96,7 @@
       (FUNCTION [function_formal_parameter_list] RETURN expression)
 
     function_formal_parameter_list ::=
-      formal_part | (identifier {, identifier})
+      formal_part | (defining_identifier {, defining_identifier})
 
              Name Resolution Rules
 
@@ -95,7 +110,7 @@
   parameters. If the function_formal_parameter_list is a formal_part,
   then it shall be subtype conformant to the expected profile if there
   is an expected type, or merely mode conformant otherwise. If the
-  function_formal_parameter_list is a sequence of identifiers, the
+  function_formal_parameter_list is a sequence of defining_identifiers, the
   number of identifiers in the sequence shall be the same as the number
   of formal parameters in the expected profile.
 
@@ -123,8 +138,8 @@
   by the formal_part, if provided in the anonymous_function, or by the
   formal part of the expected profile otherwise, but with the name of
   each formal parameter of the expected profile replaced by the
-  corresponding identifier in the sequence of identifiers. The expression
-  of this locally defined expression function is that of the
+  corresponding defining_identifier in the sequence of identifiers. The 
+  expression of this locally defined expression function is that of the
   anonymous_function.
 
   AARM To Be Honest: Depending on the nature of the innermost enclosing
@@ -3956,7 +3971,9 @@
 >    for T'Input use (<some anonymous function>); or
 >   function F (X : T) return T renames (<some anonymous function>);
 
-I suspect these are harmless, but I agree we might as well restrict the context so they can only be used as generic formal function actuals, generic formal function defaults, callable-parameters, and callable defaults.
+I suspect these are harmless, but I agree we might as well restrict the 
+context so they can only be used as generic formal function actuals, generic
+formal function defaults, callable-parameters, and callable defaults.
 
 > .
 >
@@ -4210,5 +4227,218 @@
 at minimum there should be some sort of AARM note about conformance of 
 parameters of anonymous functions and probably some mention of conformance in 
 the !discussion.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 9, 2019  2:43 PM
+
+>>Here is a version that incorporates comments from Gary, 
+>>Steve, and Bob.
+
+>You used an older version of this as the basis, so you put back various
+>errors that I had corrected.
+
+Sorry about that.
+
+>I also had get rid of 22 extra spaces after periods. :-)
+
+And you may use those extra spaces as you see fit... ;-)
+
+---
+
+>I never saw a definitive answer to my original question about conformance of
+>anonymous function, or for that matter for the declaration in the expression
+>of the body.
+
+>The original example was:
+>
+>  package Pack is
+>     function Ugh (P : Natural := Foo ((function (A) return A*2), 2)) return Natural;
+>  end Pack;
+>
+>  package body Pack is
+>     function Ugh (P : Natural := Foo ((function (A) return A*2), 2)) return Natural is ...
+>  end Pack;
+>
+>  with Pack;
+>  procedure Main is
+>     V : Natural := Pack.Ugh;
+>  begin
+>     Put (V'Image);
+>  end Main;
+>
+>There are two issues here. 
+>
+>The lesser issue...
+>
+>The primary issue, however is how this is handled for conformance.
+>
+>Steve points to 6.3.1(21/4), which says:
+>
+>each direct_name, character_literal, and selector_name that is not part of
+>the prefix of an expanded name in one denotes the same declaration as the
+>corresponding direct_name, character_literal, or selector_name in the other,
+>or they denote corresponding declarations occurring within the two
+>expressions; and 
+>
+>It seems this works for the anonymous function itself, but I don't know if
+>it works for the (A). This is described in terms of the profile of the outer
+>declaration rather than being a declaration of its own, and while I suppose
+>we could just handwave it (it has to be some sort of declaration if it is
+>making a name visible), we should at least make that handwaving explicit
+>with an AARM note.
+>
+>Note that depending on this rule means that the ids in the profiles don't
+>have to be the same, they just have to denote the same parameter:
+>
+>  package Pack is
+>     function Ugh (P : Natural := Foo ((function (A) return A*2), 2)) return Natural;
+>  end Pack;
+>
+>  package body Pack is
+>     function Ugh (P : Natural := Foo ((function (B) return B*2), 2)) return Natural is ...
+>  end Pack;
+>
+>6.3.1(20.1/4) is supposed to prevent that:
+>  corresponding defining_identifiers occurring within the two expressions
+>  are the same; and
+>
+>but it doesn't apply here as there are no defining_identifiers in the syntax
+>of an anonymous function.
+
+I would suggest we change:
+
+   function_formal_parameter_list ::=
+     formal_part | (identifier {, identifier})
+
+to be:
+
+   function_formal_parameter_list ::=
+     formal_part | (defining_identifier {, defining_identifier})
+
+because these are clearly defining identifiers, even if their type is 
+implicit.  The identifier for the loop parameter in a loop over a range is
+similar when there is no explicit type given to the range.
+
+The wording would have to change slightly as well.  E.g. in Name Resolution:
+
+ ... If the
+ function_formal_parameter_list is a sequence of defining_identifiers, the
+ number of defining_identifiers in the sequence shall be the same as the number
+ of formal parameters in the expected profile.
+
+and the Static Semantics:
+
+ ... but with the name of
+ each formal parameter of the expected profile replaced by the
+ corresponding defining_identifier in the sequence of defining_identifiers. 
+
+>Not sure if something ought to be changed to eliminate this possibility, but
+>at minimum there should be some sort of AARM note about conformance of
+>parameters of anonymous functions and probably some mention of conformance
+>in the !discussion.
+
+I think using defining_identifier resolves the problem.  If not, let me know 
+why, and I'll compose an AARM note.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 9, 2019  3:04 PM
+
+>I think using defining_identifier resolves the problem.  If not, let me 
+>know why, and I'll compose an AARM note. 
+ 
+Yes, that solves the specific problem I described. I guess there is a second 
+issue, in that the wording describes replacing identifiers in "the expected 
+profile" rather than the declaration of something. A profile is what's 
+declared, not the declaration. (A profile is to a formal_part like an object 
+is to a object_declaration.) 
+ 
+That means the wording "denote corresponding declarations" in the conformance 
+rules as described above is tad dubious. A full fix would describe the 
+formal_part of the implicitly declared function in terms of the expected 
+profile and the given names. It's not clear that such a substantial change is 
+really needed, but maybe a To Be Honest somewhere?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 9, 2019  3:33 PM
+
+I think you are at the level of angels on a pin with this one.  If you look at 
+RM 8.5.4(3) you will see:
+
+"The expected profile for the callable_entity_name is the profile given in the 
+subprogram_specification."
+
+Based on this wording, the expected profile *is* the profile given in the 
+subprogram_spec.  It isn't something that is declared by that spec.  And by RM 
+6.1(22), a "profile" is a piece of a subprogram specification, not something 
+that is itself being declared.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 9, 2019  4:12 PM
+
+OK, but the wording in question only applies to entities that "denote a 
+declaration". If the profile is not declared, then the wording surely cannot 
+apply to the entities of a profile.
+
+I do see what you mean about 6.1(22), but that is utter nonsense for "expected 
+profile" and similar uses - since the syntax used to declare the profile is 
+irrelevant, you can't claim that the profile *is* syntax. This implies 
+that the form of writing entities matters for profiles (whether or not a in is 
+omitted, prefixes for subtypes, etc.). And in any case, syntax is not a 
+declaration, and we need a declaration in order to apply the conformance rule.
+
+I certainly agree that this isn't very important (surely not broken enough to 
+be worth rewriting a bunch of text), which I why I suggested a TBH note to 
+make the correspondence between the parameters names in the profile and the 
+"declaration" needed for conformance clear.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 9, 2019  4:32 PM
+
+> ...
+> 
+> OK, but the wording in question only applies to entities that "denote 
+> a declaration". If the profile is not declared, then the wording 
+> surely cannot apply to the entities of a profile.
+
+If we use a quantified expression as a model, the declaration is the loop 
+parameter specification, which doesn't necessarily have a type mentioned (e.g. 
+could be "for all B of D ...") so I think we should specify that each 
+defining_identifier within a function_formal_parameter_list is a "declaration."
+It is clearly introducing a name, even though the type is implicit from 
+context.  So I think the right fix is to modify RM 3.1(6/5):
+
+  Each of the following is defined to be a "declaration": any 
+  basic_declaration; an enumeration_literal_specification; a 
+  discriminant_specification; a component_declaration; an 
+  iterated_component_association; a loop_parameter_specification; an 
+  iterator_specification; a parameter_specification; a subprogram_body; 
+  an extended_return_object_declaration; an entry_declaration; 
+  an entry_index_specification; a choice_parameter_specification; 
+  a generic_formal_parameter_declaration 
+  {; a defining_identifier of a function_formal_parameter_list}.
+
+We could move it earlier in this list if the list is in some sort of order 
+(e.g. based on where the construct appears in the manual).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 10, 2019  9:16 PM
+
+Looks good. And yes, these are in the order they appear in the RM, so the 
+new item should go between iterated_component_specification and 
+loop_parameter_specification.
+
+I've updated AI12-0190-1 this way. [This is version /08 of the AI - Editor.]
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent