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