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

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

--- ai12s/ai12-0282-1.txt	2018/06/12 05:28:47	1.3
+++ ai12s/ai12-0282-1.txt	2019/03/08 01:09:30	1.4
@@ -1,84 +1,100 @@
-!standard C.6(6.1/3)                                  18-06-05  AI12-0282-1/01
+!standard C.6(6.1/3)                                  19-03-07  AI12-0282-1/02
 !standard C.6(6.3/3)
 !standard C.6(6.5/3)
+!standard C.6(6.8/3)
 !standard C.6(12/3)
 !class Amendment 18-06-05
 !status work item 18-06-05
 !status received 18-05-19
 !priority Low
 !difficulty Easy
-!subject Atomic and Volatile generic formal types
+!subject Atomic, Volatile, and Independent generic formal types
 !summary
 
-Aspect Atomic, Volatile, Atomic_Components, and Volatile_Components are 
-specifiable for generic formal types.
+Aspects Atomic, Volatile, Independent, Atomic_Components,
+Volatile_Components, and Independent_Components are specifiable for
+generic formal types.
 
 !problem
 
-One of the most important additions to Ada 2012 is the added support for contracts.
+One of the most important additions to Ada 2012 is the support for contracts.
 A contract allows the creator of an abstraction to better specify the intended use
-of the abstraction. Certain aspects such as Nonblocking can be specified for 
-generic formal types, which allows making more precise assumptions about the 
-actuals within the body of the generic. Currently the Atomic, Atomic_Components, 
-Volatile, and Volatile_Components aspects cannot be specified for a generic formal 
-type. To enable programmers to create generic abstraction data types that be
-updated atomically or treated as volatile object, should Ada allow the aspects 
-Atomic, Atomic_Components, Volatile, and Volatile_Components to be specified on a 
-generic formal type? -- Yes.
+of the abstraction. Certain aspects such as Nonblocking can be specified for
+generic formal types, which allows making more precise assumptions about the
+actuals within the body of the generic. Currently the Atomic, Atomic_Components, Volatile,
+Volatile_Components, Independent, and Independent_Components aspects
+cannot be specified for a generic formal type. To enable programmers to
+create generic abstract data types that can be updated atomically or
+treated as volatile objects, Ada should allow the aspects Atomic,
+Atomic_Components, Volatile, Volatile_Components, Independent, and
+Independent_Components to be specified on a generic formal type.
 
 !proposal
 
-See Summary.
+(See Summary.)
 
 !wording
 
-Modify C.6 (6.1/3)  -- to allow aspect Atomic or Volatile to be applied to a generic formal type
+Modify C.6(6.1/3): -- to allow aspect Atomic, Volatile, or Independent
+                   -- to be applied to a generic formal type
 
-  For an object_declaration, a component_declaration, 
- {full_type_declaration,} or a  {formal_complete}[full]_type_declaration, the 
- following representation aspect[s] may be
-  specified:
-
-Move C.6 (6.3/3 - 6.b/3) after 6.c/3 -- to allow Atomic and Volatile to be grouped together
-  
-Add before what currently is C.6 (6.3/3)  -- to keep Independent the way it was
-
-  For an object_declaration, a component_declaration, or a full_type_declaration,
-  the following representation aspects may be specified:
-
-Modify C.6 (6.5/3)  -- to allow Atomic_Components and Volatile_Components to be 
-                    -- applied to a generic formal array type
-
-For a full_type_declaration of an array type (including the anonymous type of an 
-object_declaration of an anonymous array object), {or a formal_complete_type_declaration 
-of a formal array type} the following representation aspects may be specified:
-
-Modify C.6 (12/3)
-If an atomic object is passed as a parameter, then the formal parameter shall 
-either have an atomic type or allow pass by copy. If an atomic object is used as 
-an actual for a generic formal object of mode in out, then the type of the 
-generic formal object shall be atomic. If the prefix of an attribute_reference 
-for an Access attribute denotes an atomic object [(including a component)], then 
-the designated type of the resulting access type shall be atomic. {If a generic
-formal type is atomic, then the actual shall be atomic. If a generic formal
-type has atomic components, then the actual shall have atomic components.} 
-If an atomic type is used as an actual for a generic formal derived type, then 
-the ancestor of the formal type shall be atomic. Corresponding rules apply to 
-volatile objects and types. 
+  For an object_declaration, a component_declaration, [or] a
+  full_type_declaration{, or a formal_complete_type_declaration}, the
+  following representation aspect[s] may be specified:
+
+Modify C.6(6.5/3): -- to allow Atomic_Components, Volatile_Components, and
+                   -- Independent_Components to be applied to a generic
+                   -- formal array type; also make existing wording
+                   -- more consistent with how aspect Pack is defined.
+
+  For [a full_type_declaration]{the full type declaration} of an array
+  type (including the anonymous type [of] {defined by an
+  array_type_definition within} an object_declaration [of an anonymous
+  array object]){, or the formal_complete_type_declaration of a formal
+  array type}, the following representation aspects may be specified:
+
+Modify C.6(6.8/3):  --  Allow Independent_Components on a generic formal
+                    --  composite type; also make existing wording
+                    --  more consistent with how aspect Pack is defined.
+
+  For [a full_type_declaration] {the full type declaration of a
+  composite type} (including the anonymous type [of] {defined by a full
+  type definition within} an object_declaration [of an anonymous array
+  object]){, or the formal_complete_type_declaration of a formal
+  composite type}, the following representation aspect may be specified:
+
+Add after C.6(12/3):
+
+  If the Atomic, Atomic_Components, Volatile, Volatile_Components,
+  Independent, or Independent_Components aspect is True for a
+  generic formal type, then that aspect shall be True for the actual
+  type.
 
 !discussion
 
-We considered whether other related aspects such as Independent, or 
-Independent_Components should also be allowed to be specified for generic formal 
-types. We decided against that because it wasn't clear that such a capability would
-be conceivably useful. We considered whether Atomic_Components should be allowed
-or not. With the new capabilities of AI12-0234-1, conceivably one might want to 
-apply atomic operations to elements of an array, such as an array of counters.
-The point of the atomic operation libraries of AI12-0234-1 is to allow programmers
-to create useful abstractions, and so Atomic_Compenents was allowed. This left
-Volatile and Volatile_Components. There is less of a need to support these as
-generic formals, but since they are closely related to atomic types it seemed 
-somewhat better to allow these, which also fit in better with the wording in the RM.
+For uniformity, we have allowed Independent and Independent_Component
+aspects on generic formal types, even though the capability is not as
+critical as that for atomic and volatile. However, independent
+addressability becomes more important as we move toward more
+parallelism, since two logical threads can concurrently manipulate
+different components of the same object only if they are independently
+addressable. We considered whether Atomic_Components should be allowed
+or not. With the new capabilities of AI12-0234-1, conceivably one might
+want to apply atomic operations to elements of an array, such as an
+array of counters. The point of the atomic operation libraries of
+AI12-0234-1 is to allow programmers to create useful abstractions, and
+so Atomic_Compenents was allowed. This left Volatile and
+Volatile_Components. There is less of a need to support these as generic
+formals, but since they are closely related to atomic types it seemed
+somewhat better to allow these, which also fit in better with the
+wording in the RM.
+
+We adjusted some of the existing wording, as it was written during the
+massive switch from pragmas to aspects, and was a bit awkward (e.g.
+"including the anonymous type of an object_declaration of an anonymous
+array object" doesn't really make sense, because the array object is not
+anonymous, and the declaration doesn't have a type, since it is the
+declared object that has an anonymous type).
 
 !ASIS
 
@@ -93,25 +109,25 @@
 From: Brad Moore
 Sent: Friday, May 18, 2018  11:27 PM
 
-Here is one of the offspring of AI12-0234-1 (Compare and Swap atomic 
+Here is one of the offspring of AI12-0234-1 (Compare and Swap atomic
 operations) [This is version /01 of this AI - Editor.]
 
-This AI specifically is to allow Atomic, Atomic_Components, Volatile, and 
+This AI specifically is to allow Atomic, Atomic_Components, Volatile, and
 Volatile_Components to be specified on a generic formal type declaration.
 
-AI12-0234-1 depends on this AI. It really only needs to allow Atomic to be 
-specified on generic formal types, but allowing Atomic_Components seemed useful 
-also, since one can easily imagine programmers creating abstractions with the 
+AI12-0234-1 depends on this AI. It really only needs to allow Atomic to be
+specified on generic formal types, but allowing Atomic_Components seemed useful
+also, since one can easily imagine programmers creating abstractions with the
 packages defined in AI12-0234-1, that operate on arrays.
 
-Given those two aspects, it seems natural to also allow Volatile and 
-Volatile_Components, even though it is not as easy to think of cases where 
-these two aspects would be useful, but allowing them seemed to fit better 
+Given those two aspects, it seems natural to also allow Volatile and
+Volatile_Components, even though it is not as easy to think of cases where
+these two aspects would be useful, but allowing them seemed to fit better
 into the language, than leaving them out.
 
-The aspects Independent and Independent_Components were left out because it 
-was quite a bit even more difficult to think of possible use for these, and 
-those two aspects seem less coupled to Atomic than Volatile, so it was easier 
+The aspects Independent and Independent_Components were left out because it
+was quite a bit even more difficult to think of possible use for these, and
+those two aspects seem less coupled to Atomic than Volatile, so it was easier
 to leave them out.
 
 ****************************************************************
@@ -129,18 +145,18 @@
 
 !discussion
 
-We considered whether other related aspects such as Independent, or 
+We considered whether other related aspects such as Independent, or
 Independent_Components{,} should also be allowed to be specified for generic
 formal
 
 or
 
-We considered whether other related aspects such as Independent[,] or 
+We considered whether other related aspects such as Independent[,] or
 Independent_Components should also be allowed to be specified for generic
 formal
 
 
-We decided against that because it wasn't clear that such a capability 
+We decided against that because it wasn't clear that such a capability
 {could conceivably be} [would be conceivably] useful.
 
 somewhat better to allow these, which also fit{s} in better with the wording
@@ -148,7 +164,70 @@
 
 or
 
-somewhat better to allow these, which {would} also fit in better with the 
+somewhat better to allow these, which {would} also fit in better with the
 wording in the RM.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March  7, 2019  4:09 PM
+
+Here is an update to AI12-0282-1, about applying the shared-variable aspects to
+generic formal types.  The update incorporates the the changes we discussed
+during the last ARG phone meeting.  I also discovered that some of the existing
+wording in C.6 didn't make a lot of sense, so I cleaned that up a bit.
+
+[This is version /02 of the AI - Editor.]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, March  7, 2019  6:55 PM
+
+> Here is an update to AI12-0282-1,
+
+...
+>  For [a full_type_declaration] {the full type declaration of a
+> composite type} (including the anonymous type [of] {defined by a full
+> type definition within} an object_declaration [of an anonymous array
+> object]){, or the formal_complete_type_declaration of a formal
+> composite type}, the following representation aspect may be specified:
+
+According to both 3.2.1 and index, we have "full type definition" and
+"full_type_declaration", but not "full type declaration". I realize that we
+sometimes informally use terms without the underscores, but in such cases they
+mean the same thing as the syntax term. Sometimes we define the English terms to
+mean something different (as in "function call" vs. "function_call"), but let's
+not go there again.
+
+And it's pretty clear from the RM that an object_declaration with an anonymous
+array type is never a full_type_declaration (or full type declaration, for that
+matter). It *is* a "full type definition", but those don't have aspects. There's
+no way syntactically to specify an aspect for an anonymous type.
+
+The aspect is *defined* for an object (of an anonymous array type), and
+*applies* to the anonymous type of the object. (It's impossible to give an
+aspect on an anonymous array definition, there's no syntax for that.)
+
+I also realize that I probably was the original source of this bug (I vaguely
+recall a discussion like this years ago), but in any case, if we're going to fix
+this, we need to do it right. Otherwise, replacing one set of wavy-gravy wording
+with another isn't helping anything.
+
+So I think the lead-in has to say something like:
+
+  For the full_type_declaration of a composite type, the
+  formal_complete_type_declaration of a formal composite type,
+  or an object_declaration with an array_type_definition (in this
+  case, the aspect specified is that of the anonymous array type
+  of the type definition, not of the object), the following
+  representation aspect may be specified:
+
+We have to talk about the aspect being specified on an object_declaration
+('cause that's where it is specified) and applying to the type (because that's
+where it's meaningful).
+
+Thoughts, improvements??
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent