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

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0427-1.txt

--- ai12s/ai12-0427-1.txt	2021/05/28 04:51:46	1.3
+++ ai12s/ai12-0427-1.txt	2021/05/30 00:26:28	1.4
@@ -1,14 +1,18 @@
-!standard 3.5(56.4/3)                                   21-05-27  AI12-0427-1/03
+!standard 3.5(56.4/3)                                   21-05-29  AI12-0427-1/04
 !standard 3.6(22.2/3)
+!standard 4.1.3(13.1/5)
 !standard 4.2.1(0/5)
 !standard 4.3.5(0/5)
 !standard 4.5.10(0/5)
+!standard 4.9.1(2/3)
 !standard 4.10(0/5)
+!standard 5.6.1(0/5)
 !standard 8.5(5)
 !standard 8.6(17.1/5)
 !standard 9.10.1(26/5)
 !standard 13.1(10/5)
 !standard 13.1(13.1/3)
+!standard 13.1.1(11/5)
 !standard 13.1.1(21/3)
 !standard 13.1.1(22/3)
 !standard 13.3(6)
@@ -57,6 +61,19 @@
 
 (13) Clarify what is passed to xxx_Literal functions.
 
+(14) Add an aspect_specification to parallel blocks.
+
+(15) Restrict the deferred resolution of aspect_specifications to those
+appearing on a declaration.
+
+(16) 4.1.3(13.1/5) needs to define the context of the Access attribute
+so that resolution is well-defined.
+
+(17) Extend 4.9.1(1.5/5) to properly account for global aspects that
+contain global_names. Also, change "statically denotes" to "statically
+names" in 6.1.1(9/5) to allow as many names as possible to be used in a
+global aspect.
+
 !problem
 
 (1) Stream-oriented attributes define the subtype of the parameter of the 
@@ -207,6 +224,52 @@
 as a numeric literal? At a minimum it needs enclosing quotation marks. This
 needs to be better specified.
 
+(14) AI12-0355-2 adds aspect_specifications to "all constructs that use the
+reserved word parallel". But that was not done for a parallel block, which
+uses the reserved work parallel.
+
+(15) AI12-0355-2 as well as the previous issue add aspect_specifications to
+certain statements and expressions. 13.1.1(11/5) says:
+
+  The usage names in an aspect_definition are not resolved at the point of the
+  associated declaration, but rather are resolved at the end of the
+  immediately enclosing declaration list, or in the case of the declaration of
+  a library unit, at the end of the visible part of the entity.
+
+This doesn't make sense when an aspect_specification is associated with
+something other than a declaration -- we might not even directly be in a
+declaration list (and the declaration list containing a body is way too late).
+
+(16) 4.1.3(13.1/5) says:
+
+For a prefixed view of a subprogram whose first parameter is an access 
+parameter, the prefix shall be legal as the prefix of an Access attribute 
+reference.
+
+There are two problems with this. First, an Access
+attribute reference normally occurs in some specific context
+that, for example, defines its expected type. That is not the case here,
+and given that the resolution of the prefix of an Access attribute depends
+on the expected type, it is not completely clear what this wording means.
+
+Second, Ada doesn't define an "attribute reference". There is an implicit
+definition as an "attribute_reference", but that doesn't explain how the
+identifier is associated. Other uses use the longer but clearly correct 
+"an attribute_reference with attribute_designator Blah". We should either
+define "attribute reference" properly, or use the longer wording.
+
+(17) The statically matching rule for Global aspects (4.9.1(1.5/5) says
+... or each is of the form “global_mode global_designator” with
+the same sequence of reserved words.
+But a global_designator can be a global_name, so it seems like we need
+a requirement that corresponding global_names have to statically denote
+the same entity.
+
+Additionally, we now has "statically names" for objects, which allows
+selected and indexed names when those are known at compile-time. We should
+use that in 6.1.2(9/5) and in 4.9.1(1.5/5) to allow as much as possible in
+global aspects.
+
 !proposal
 
 (1) Add appropriate wording.
@@ -240,6 +303,15 @@
 
 (13) Clarify what is passed to xxxx_Literal functions.
 
+(14) Add an aspect_specification to a parallel block, and update the semantics
+to include it.
+
+(15) (See summary.)
+
+(16) (See summary.)
+
+(17) (See summary.)
+
 !wording
 
 [Editor's note: These changes have been applied to Draft 30 of the RM, even
@@ -433,6 +505,59 @@
     by the original string} [having the textual representation of the original 
     (numeric or string)] literal.
 
+(14) Replace 5.6.1(2/5) with:
+
+parallel_block_statement ::= 
+    parallel [aspect_specification] do
+       handled_sequence_of_statements
+    and
+       handled_sequence_of_statements
+   {and
+       handled_sequence_of_statements}
+    end do;
+
+Modify 5.6.1(3/5):
+
+   {For the execution of a parallel_block_statement, the aspect_specification, 
+   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{, 
+   each of which} represents a separate logical thread of control{, 
+   executes}[ that proceeds] independently and concurrently. The 
+   parallel_block_statement is complete once every one of the 
+   handled_sequence_of_statements has completed, either by reaching the end 
+   of its execution, or due to a transfer of control out of the construct by
+   one of the handled_sequence_of_statements (see 5.1).
+
+(15) Modify 13.1(11/5):
+
+   The usage names in an aspect_definition {associated with a declaration}
+   [Redundant: are not resolved at the point of the associated declaration,
+   but rather] are resolved at the end of the immediately enclosing declaration
+   list, or in the case of the declaration of a library unit, at the end of 
+   the visible part of the entity.
+
+(16) Modify 4.1.3(13.1/5):
+
+   For a prefixed view of a subprogram whose first {formal} parameter is an 
+   access parameter, the prefix shall be legal as the prefix of an
+   {an attribute_reference with attribute_designator} Access 
+   [attribute reference] {appearing as the first actual parameter in a call on
+   the unprefixed view of the subprogram}.
+
+(17) Modify 4.9.1(1.5/5):
+
+   The Global or Global'Class aspects (see 6.1.2) of two entities statically
+   match if both consist of a single global_aspect_definition where each is 
+   the reserved word null, or each is of the form 
+   “global_mode global_designator” with {each global_mode being} the same
+   sequence of reserved words {and each global_designator being the same 
+   reserved word, or each being a global_name that statically denotes the 
+   same entity}.
+
+Modify 6.1.2(9/5):
+
+   A global_name shall resolve to statically {name}[denote] an object or 
+   a package (including a limited view of a package). 
+
 !discussion
 
 (1) The first paragraph is modeled on that found in 13.13.2(51/3) for
@@ -561,6 +686,32 @@
 (13) Indeed, the intent is that no enclosing quotes are passed to these 
 routines. That needed to be made explicit.
 
+(14) All of the reasons that it is useful to have an aspect_specification on a
+parallel loop (the ability to specify properties to an underlying scheduler
+in particular) certainly apply to a parallel block.
+
+(15) The reason for deferring names in a declaration is so that subprograms
+and objects declared after a subprogram or type can be used in aspects
+like preconditions and stream attributes. This is necessary for types as
+one cannot declare a subprogram with a parameter of a type *before* the
+type is declared (and is convinient in other cases). This need does not 
+apply to statements and expressions, so we resolve the aspect_definitions
+immediately.
+
+(16) The term "attribute reference" is not defined, and as the !problem
+states, it is not just an alternative for the syntax term
+"attribute_reference". Defining a term for this probably would be preferable
+for readability, but given the possibility of the definition introducing
+new bugs, it is just too late in the definition of Ada 202x to do that.
+So we use the more pedantic wording. 
+
+(17) Since "statically names" is defined to be equivalent to "statically
+denotes" for entities that are not objects, we can use it without
+qualification in 6.1.1(9/5).
+
+Since 6.1.1(9/5) requires a global_name to statically name something,
+we can require the same for static matching.
+
 !corrigendum 3.5(56.4/3)
 
 @drepl
@@ -583,6 +734,17 @@
 If a derived type inherits a boolean Default_Component_Value
 aspect, the aspect may be specified to have any value for the derived type.
 
+!corrigendum 4.1.3(13.1/5)
+
+@drepl
+For a prefixed view of a subprogram whose first parameter is an access parameter,
+the prefix shall be legal as the prefix of an Access attribute reference.
+@dby
+For a prefixed view of a subprogram whose first formal parameter is an access
+parameter, the prefix shall be legal as the @fa<prefix> an
+@fa<attribute_reference> with @fa<attribute_designator> Access appearing as
+the first actual parameter in a call on the unprefixed view of the subprogram.
+
 !corrigendum 4.2.1(0)
 
 @dinsc
@@ -598,11 +760,53 @@
 @dinsc
 See the conflict file for the changes.
 
+!corrigendum 4.9.1(2/3)
+
+@drepl
+A subtype @i<statically matches> another subtype of the same type if they have
+statically matching constraints, all predicate specifications that apply to
+them come from the same declarations, and, for access subtypes, either both or
+neither exclude null. Two anonymous access-to-object subtypes statically match
+if their designated subtypes statically match, and either both or neither
+exclude null, and either both or neither are access-to-constant. Two anonymous
+access-to-subprogram subtypes statically match if their designated profiles are
+subtype conformant, and either both or neither exclude null. 
+@dby
+The Global or Global'Class aspects (see 6.1.2) of two entities @i<statically
+match> if both consist of a single @fa<global_aspect_definition>
+where each is the reserved word @b<null>, or each is of the form
+"@fa<global_mode> @fa<global_designator>" with each @fa<global_mode> being the
+same sequence of reserved words and each @fa<global_designator> being the same 
+reserved word, or each being a @fa<global_name> that statically denotes the 
+same entity.
+
+A subtype @i<statically matches> another subtype of the same type if they have
+statically matching constraints, all predicate specifications that apply to
+them come from the same declarations, Nonblocking aspects have the same value, 
+global aspects statically match, Object_Size (see 13.3) has been specified
+to have a nonconfirming value for either both or neither, and the nonconfirming
+values, if any, are the same, and, for access subtypes, either both or
+neither exclude null. Two anonymous access-to-object subtypes statically match
+if their designated subtypes statically match, and either both or neither
+exclude null, and either both or neither are access-to-constant. Two anonymous
+access-to-subprogram subtypes statically match if their designated profiles are
+subtype conformant, and either both or neither exclude null. 
+
 !corrigendum 4.10(0)
 
 @dinsc
 See the conflict file for the changes.
 
+!corrigendum 5.6.1(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 6.1.2(0)
+
+@dinsc
+See the conflict file for the changes.
+
 !corrigendum 8.5(5)
 
 @ddel
@@ -670,6 +874,22 @@
 and the convention shall be Ada. Additional requirements are defined for
 particular aspects. 
 
+!corrigendum 13.1.1(11/5)
+
+@drepl
+The usage names in an @fa<aspect_definition> are not resolved at the
+point of the associated declaration, but rather are resolved at the
+end of the immediately enclosing declaration list, or in the
+case of the declaration of a library unit, at the end of the visible
+part of the entity.
+@dby
+The usage names in an @fa<aspect_definition> associated with a declaration
+are not resolved at the point of the associated declaration, but rather 
+are resolved at the end of the immediately enclosing declaration list, 
+or in the case of the declaration of a library unit, at the end of the visible
+part of the entity.
+
+
 !corrigendum 13.1.1(21/3)
 
 @drepl
@@ -1330,5 +1550,177 @@
     of characters in the original numeric literal, or the sequence represented 
     by the original string} [having the textual representation of the original 
     (numeric or string)] literal.
+
+****************************************************************
+
+From the WG 9 review, issue #176.
+
+AI12-0355-2 starts as follows:
+
+    All constructs that include the word "parallel" now permit an
+    aspect_specification as part of their syntax.
+
+    !problem
+
+    We need a mechanism to pass information through to a lightweight
+    parallelism scheduler. Something like an aspect specification might be a
+    good way to specify such options.
+
+    !proposal
+
+    We propose to add an aspect_specification to every place the PARALLEL
+    keyword is envisioned currently ...
+
+In fact, we somehow missed the parallel block feature. All of the above logic
+applies to a parallel block, so it makes sense to allow an aspect clause 
+there. Hence, 5.6.1(2/5) should probably be replaced with
+
+parallel_block_statement ::= 
+    parallel [aspect_specification] do
+       handled_sequence_of_statements
+    and
+       handled_sequence_of_statements
+   {and
+       handled_sequence_of_statements}
+    end do;
+
+The "static semantics" section is mislabeled, and should be labeled "dynamic 
+semantics" (also mentioned by Issue #169). RM 5.6.1(3/5) should be updated as
+follows:
+
+   {For the execution of a parallel_block_statement, the aspect_specification, 
+   if any, is elaborated. Then every}[Each] handled_sequence_of_statements{, 
+   each of which} represents a separate logical thread of control{, 
+   executes}[ that proceeds] independently and concurrently. The 
+   parallel_block_statement is complete once every one of the 
+   handled_sequence_of_statements has completed, either by reaching the end 
+   of its execution, or due to a transfer of control out of the construct by
+   one of the handled_sequence_of_statements (see 5.1).
+
+****************************************************************
+
+Inspired by the above:
+
+All of this (incorrect) talk about visibility and resolution of aspect
+ specifications along with thinking about adding aspect_specifications to 
+parallel blocks (and other statements and expressions) caused me to wonder 
+about resolution in those aspect_specifications.
+
+Specifically, 13.1.1(11/5) says:
+
+The usage names in an aspect_definition are not resolved at the point of 
+the associated declaration, but rather are resolved at the end of the 
+immediately enclosing declaration list, or in the case of the declaration 
+of a library unit, at the end of the visible part of the entity.
+
+What if this aspect_definition is part of an aspect_specification that's 
+in a loop or block or if statement etc??? What the heck declaration list 
+are we talking about -- the one enclosing the body is way too late and there
+isn't one in the sequence_of_statements. (It's better for an 
+aspect_specification in an expression, such as an aggregate or quantified 
+expression, if that expression is part of some declaration, but it still 
+means resolution is mighty late. Of course, we have a rule - 13.1.1(13/3) - 
+that the resolution has to match at the freezing point of the declaration, 
+but how that applies to an expression that is only loosely tied to a 
+declaration isn't clear.)
+
+I think we patched up the freezing rules for this statement/expression case 
+(yes, we did, see 13.14(7.2/5)), but not the resolution rules. Yikes!!
+
+Am I right? Do we have a significant last minute issue here??
+
+[Tucker Taft replied:]
+
+I agree that we should limit the notion of "deferred" name resolution to cases
+where we are talking about an aspect specification on a declaration.  Hence:
+
+Modify 13.1(11/5):
+
+The usage names in an aspect_definition {associated with a declaration}
+[Redundant: are not resolved at the point of the associated declaration, but
+rather] are resolved at the end of the immediately enclosing declaration list,
+or in the case of the declaration of a library unit, at the end of the visible
+part of the entity.
+
+
+****************************************************************
+
+From the WG 9 review, issue #132 - Steve Baird.
+
+We could quibble over 13.1/5 wording regarding "shall be legal as
+the prefix of an Access attribute reference", since an Access
+attribute reference normally occurs in some specific context
+that, for example, defines its expected type. So it is, arguably at
+least, not completely clear what this wording means.
+[Randy suggests that this does indeed warrant some action, and that
+the fix is easy.]
+
+===
+
+This also illustrates an RM consistency issue that should be
+cleaned up at some point (but not now). Here we use the (good
+& desirable) terminology "an Access attribute reference". At other places
+in the RM (e.g., 6.1.1(8)), we use pedantic, contorted wording
+like "an attribute_reference with attribute_designator Old".
+That sort of thing should be replaced with "an Old attribute reference".
+
+If it seems appropriate, we could add a definition saying that
+an " attribute reference" is an attribute_reference
+having the given attribute name as its attribute_designator. Or we
+could decide that this is sufficiently obvious that it does not need
+to be stated explicitly.
+
+[Randy suggests either we should explicitly define this new term or
+we should avoid the shorter terminology that I prefer. He doesn't like
+using this shorter terminology without properly defining it. I'm
+inclined to agree.]
+
+[Tucker Taft responds:]
+
+For the first part, I would suggest:
+Modify 4.1.3(13.1/5):
+For a prefixed view of a subprogram whose first {formal} parameter is an 
+access parameter, the prefix shall be legal as the prefix of an Access 
+attribute reference {appearing as the first actual parameter in a call on
+the unprefixed view of the subprogram}.
+
+[The Editor responds:]
+
+The second part is easy to fix in this rule, just use the defined terminology:
+
+Modify 4.1.3(13.1/5):
+For a prefixed view of a subprogram whose first {formal} parameter is an 
+access parameter, the prefix shall be legal as the prefix of an
+{an attribute_reference with attribute_designator} Access 
+[attribute reference] {appearing as the first actual parameter in a call on
+the unprefixed view of the subprogram}.
+
+No one is interested in spelunking the RM for other places where we use
+inprecise terminology, and adding a term is too much at this point.
+
+****************************************************************
+
+From the WG 9 review, issue #142 - Steve Baird.
+
+The statically matching rule for Global aspects (4.9.1(1.5/5) says
+... or each is of the form “global_mode global_designator” with
+the same sequence of reserved words.
+But a global_designator can be a global_name, so it seems like we need
+a requirement that corresponding global_names have to statically denote
+the same entity, or something like that.
+
+[Tucker Taft responds:]
+
+I would suggest:
+
+Modify 4.9.1(1.5/5)
+
+   The Global or Global'Class aspects (see 6.1.2) of two entities statically
+   match if both consist of a single global_aspect_definition where each is 
+   the reserved word null, or each is of the form 
+   “global_mode global_designator” with {each global_mode being} the same
+   sequence of reserved words {and each global_designator being the same 
+   reserved word, or each being a global_name that statically denotes the 
+   same entity}.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent