CVS difference for 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