CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/04/02 07:30:36 1.14
+++ ai05s/ai05-0229-1.txt 2011/04/15 05:29:06 1.15
@@ -1,4 +1,4 @@
-!standard 13.2(5) 11-04-01 AI05-0229-1/08
+!standard 13.2(5) 11-04-14 AI05-0229-1/09
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
@@ -309,29 +309,30 @@
the following representation aspects can be specified: Atomic, Volatile,
and Independent.
-For an object declaration of an anonymous array object or
-a full type declaration of an array type, the following representation aspects
-can be specified: Atomic_Components, and Volatile_Components.
+For a full type declaration of an array type (including the anonymous type of
+a object_declaration of an anonymous array object), the following representation
+aspects can be specified: Atomic_Components, and Volatile_Components.
+
+For an object declaration of a full type declaration (including the anonymous type of
+a object_declaration of an anonymous array object), the following representation
+aspect can be specified: Independent_Components.
-For an object declaration of an anonymous array object or a full type declaration,
-the following representation aspect can be specified: Independent_Components.
-
The type of these aspects is Boolean. If any of these aspects are directly
specified, the aspect_definition shall be a static expression. If not specified
(including by inheritance), each of these aspects are False.
An atomic type is one for which the aspect Atomic is True. An atomic
object (including a component) is one for which the aspect Atomic is True,
-or a component of an array for which the aspect Atomic_Components is True,
-or any object of an atomic type, other than objects obtained by evaluating
-a slice.
+or a component of an array for which the aspect Atomic_Components is True
+for the associated type, or any object of an atomic type, other than objects
+obtained by evaluating a slice.
A volatile type is one for which the aspect Volatile is True. A Volatile
object (including a component) is one for which the aspect Volatile is
True, or a component of an array for which the aspect Volatile_Components
-is True, or any object of a volatile type. In addition, every atomic type
-or object is also defined to be volatile. Finally, if an object is volatile,
-then so are all of its subcomponents.
+is True for the associated type, or any object of a volatile type. In
+addition, every atomic type or object is also defined to be volatile.
+Finally, if an object is volatile, then so are all of its subcomponents.
Delete C.6(9/3) [Now in Annex J.]
@@ -351,16 +352,21 @@
Replace C.6(13):
-If an aspect Volatile, Volative_components, Atomic or Atomic_Components is
-True for an stand-alone constant object, then the aspect Import shall
-also be specified for it.
+If an aspect Volatile, Volative_components, Atomic or Atomic_Components is
+directly specified to have the value True for an stand-alone constant object,
+then the aspect Import shall also be specified for it.
+
+AARM To Be Honest: Volatile_Components and Atomic_Components actually are aspects
+of the anonymous array type; this rule only applies when the aspect is
+specified directly on the constant object and not when the (named) array type
+has the aspect.
It is illegal to specify the aspect Independent or Independent_Components as
True for a component, object or type if the implementation cannot provide the
independent addressability required by the aspect (see 9.10).
It is illegal to specify a representation aspect for a component, object or
-type for which the aspect Independent or Independent_Component is True,
+type for which the aspect Independent or Independent_Components is True,
in a way that prevents the implementation from providing the
independent addressability required by the aspect.
@@ -374,12 +380,6 @@
all objects of that type. All atomic objects are considered to be specified as
independently addressable.
-[Editor's Note: We could simplify this section a tiny bit more by defining the
-xxx_Components aspects to only be defined for types, and saying that specifying
-the aspect on an anonymous array object sets the aspect of the (anonymous) type.
-This is the way Priority (for one example) is defined. Doing this would simplify
-the model (especially for implementations), but would have little impact on the
-wording, so I didn't change Ed's proposal. - Randy]
===pragma Asynchronous: (the pragma is to be obsolescent)
@@ -535,120 +535,20 @@
Other pragmas:
-
-===pragma Preelaborable_Initialization (the pragma is to be obsolescent)
-Delete 10.2.1(4.1/2-4.2/2) [Now in Annex J.]
+===pragma Preelaborable_Initialization (referred to as P_I below)
-In 10.2.1(10.1/3), replace
- ..., unless pragma Preelaborable_Initialization has been applied
- to the formal type;
-with
- ..., unless the Preelaborable_Initialization aspect is True for
- the formal type.
-
-Replace 10.2.1(11.1-11.8/2) with: [This includes corrections from AI05-0028-1
-and AI05-0221-1.]
-
-The following rules specify which entities are said to be *eligible for
-preelaborable initialization*:
-
- * The partial view of a private type or private extension, a protected type
- without entry_declarations, a generic formal private type, or a generic
- formal derived type, is eligible for preelaborable initialization if
- and only if the Preelaborable_Initialization aspect is True for them. A
- protected type with entry_declarations or a task type is never eligible
- for preelaborable initialization.
-
- [Note: "Redundant" square brackets in preceding paragraph removed
- deliberately.]
-
- * A component (including a discriminant) of a record or protected type
- is eligible for preelaborable initialization if its declaration includes a
- default_expression whose execution does not perform any actions
- prohibited in preelaborable constructs as described above, or if its
- declaration does not include a default expression and its type is
- eligible for preelaborable initialization.
-
- * A derived type is eligible for preelaborable initialization if its
- parent type is eligible for preelaborable initialization and if the
- non-inherited components are all eligible for preelaborable initialization.
- However, a user-defined controlled type with an overriding Initialize
- procedure that is not a null procedure is not eligible for
- preelaborable initialization.
-
- * A view of a type is eligible for preelaborable initialization if it is an
- elementary type, an array type whose component type is eligible for
- preelaborable initialization, a record type whose components all are
- eligible for preelaborable initialization, or an interface type.
-
-For any type, the following language-defined type-related operational
-aspect is defined:
- Preelaborable_Initialization
- The type of aspect Preelaborable_Initialization is Boolean. If aspect
- Preelaborable_Initialization is True for a type, the type is said to
- have *preelaborable initialization*; conversely, if the aspect is
- False, the type does not have preelaborable initialization.
-
-[Editor's Note: This aspect has to be operational so we can specify it on
-partial views; that's not allowed for representation aspects.]
-
- For a composite type_declaration other than an incomplete_type_declaration
- and for a composite formal_type_declaration, this aspect may be specified.
- If not directly specified for a given type (including the case of derived
- type), the aspect is True if and only if the type is eligible for
- preelaborable initialization. If directly specified, the aspect_definition
- shall be a static expression. [redundant: The aspect is never inherited.]
-
- If the aspect Preelaborable_Initialization is True for a type,
- * the type shall be eligible for preelaborable initialization; and
- * the full view of the type (if any) shall be eligible for preelaborable
- initialization.
-
- If the aspect Preelaborable_Initialization is True for a generic
- formal type, then the corresponding actual type in an generic_instantiation
- shall have preelaborable initialization.
-
- In addition to the places where Legality Rules normally apply (see 12.3),
- these rules apply also in the private part of an instance of a generic unit.
-
- AARM reason: The reason why the aspect may be specified for private types,
- private extensions, and protected types is fairly clear: the properties
- of the full view determine whether the type has preelaborable initialization
- or not; in order to preserve privacy we need a way to express on the
- partial view that the full view is well-behaved. The reason for supporting
- this for other composite types is more subtle: a non-null override
- for Initialize might occur in the private part, even for a nonprivate type;
- in order to preserve privacy, we need a way to express on a type declared in
- a visible part that the private part does not contain any nasty override of
- Initialize.
-
- AARM ramification: A value of True may not be specified for the
- Preelaborable_Initialization aspect of a protected types with one
- or more entry_declarations or of a task type.
-
-[Editor's note: The Static Semantics and Legality Rules are all mixed together
-here. We typically don't do that, but since we already did that in the past, it
-is left that way here.]
-
-In 10.2.1(15.a/3). replace
- "; the type still could have a pragma Preelaborable_Initialization given"
-with
- "; the Preelaborable_Initialization aspect of the type could still be True"
-
-
-[Editor's Note: This aspect can be specified on generic formal types. Thus
-the AI05-0183-1 statement that there are none is a lie. Gotta fix it.]
-
-Replace the penultimate paragraph in Static
-Semantics for AI05-0183-1/11 [13.3.1(33/3) in draft 11.5]:
-
-There are no language-defined aspects that may be specified on a renaming_declaration
-and only Preelaboration_Initialization (see 10.2.1) can be specified on a
-formal_type_declaration.
+[Editor's Note: This pragma does not work well as a type-related aspect,
+as it is view dependent. In particular, even if a partial view does not
+have the P_I property, the full view might have the P_I property. That is
+contrary to 13.1(11/2) for operational and representation aspects. (In the
+absence of a change to 13.1(11/2), we'd have a compatibility problem.)
+
+We could try to invent new rules specifically for the P_I aspect to handle
+this, but it is more work than this could possibly be worth (there is no
+requirement for this pragma to be an aspect).
-[Editor's Note: Pragma Preelaborable_Initialization is used in around 20
-language-defined packages; should these all be changed??]
+Thus we are retaining the pragma and not defining an aspect.]
===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent)
@@ -793,6 +693,12 @@
Delete 13.3(62-65) [Now in Annex J.]
+Add after 13.3(65):
+
+Legality Rules
+
+The Storage_Size aspect shall not be specified for a task interface type.
+
Replace 13.3(66) with:
When a task object is created, the expression (if any) associated with the
@@ -844,9 +750,8 @@
[Editor's note: Task types and protected types cannot be derived, and
subprograms never inherit aspects, so we don't have to worry about aspect
-inheritance, other than from synchronized interfaces (a new possibility). Should
-we make specifying the aspects for those illegal?? The inabilility to derive
-also means we cannot run afoul of 13.1(10).]
+inheritance, other than from synchronized interfaces (which we don't allow anyway).
+The inabilility to derive also means we cannot run afoul of 13.1(10).]
Replace D.1(8):
@@ -860,6 +765,9 @@
AARM Ramification: This includes specifying via pragmas (see J.15.7).
+Neither of the Priority or Interrupt_Priority aspects shall be specified for a
+synchronized interface type.
+
Delete D.1(13). [This is covered by other wording, and seems to conflict with
D.1(17) anyway. The definition of the value of the pragma is never used
anywhere, so far as I can tell.]
@@ -942,11 +850,14 @@
[Editor's Note: See the comment about "single task" in Storage_Size.]
+Legality Rules
+
+The Relative_Deadline aspect shall not be specified on a task interface type.
+
[Editor's note: Task types cannot be derived, and subprograms never
inherit aspects, so we don't have to worry about aspect inheritance, other than
-from task interfaces (a new possibility). Should we make specifying the aspects
-for those illegal?? The inabilility to derive also means we cannot run afoul of
-13.1(10).]
+from task interfaces (which we don't want to allow anyway). The inabilility to
+derive also means we cannot run afoul of 13.1(10).]
Replace D.2.6(12/2):
@@ -986,15 +897,16 @@
[Editor's note: Task types cannot be derived, and subprograms never
inherit aspects, so we don't have to worry about aspect inheritance, other than
-from task interfaces (a new possibility). Should we make specifying the aspects
-for those illegal?? The inabilility to derive also means we cannot run afoul of
-13.1(10).]
+from task interfaces (which we don't allow anyway). The inabilility to derive
+also means we cannot run afoul of 13.1(10).]
Delete D.16(10/3). [Now in Annex J.]
Replace D.16(11/3) with:
If the CPU aspect is specified for a subprogram, the expression shall be static.
+The CPU aspect shall not be specified on a task interface type.
+
Modify D.16(12-4/3):
The expression [of a CPU pragma that appears in a task_definition]{specifed for
@@ -1248,11 +1160,48 @@
function Exp (X : Float) return Float
with Import => True, Convention => Fortran;
end Fortran_Library;
+
+In B.3(1/2), B.4(1), and B.5(1) change "the Import, Export and Convention pragmas" to
+"the Convention aspect" (the aspects Import and Export don't imply a convention).
+B.4(99), change "pragmas" to "aspects". In B.3(60.13/1), B.3(61/1), B.4(92), and B.5(20)
+change "pragma Convention" to "the aspect Convention". In B.4(106, 107, 115) and B.5(30),
+replace the pragmas with equivalent aspects.
+
+Replace B.3(62.1-62.4/3) with:
+
+An implementation need not support specifying the Convention aspect in the following cases:
+* the Convention aspect specifying convention C for a subprogram that has a parameter of an
+ unconstrained array subtype, unless the Import aspect has the value True for the subprogram;
+* the Convention aspect specifying convention C for a function with an unconstrained array
+ result subtype;
+* the Convention aspect specifying convention C for an object whose nominal subtype is an
+ unconstrained array subtype.
+
+[Editor's note: None of these cases are types, so I have no idea why C_Pass_By_Copy is mentioned
+in the original text. (B.3(60.13/1) says C_Pass_By_Copy can only be used on a type.)]
+[Editor's Note: Need to scrub AARM notes for "pragma Import", "pragma Export",
+and "pragma Convention". All of the notes in B.1 need to be rewritten, too.
+Includes B.4(91.j), 6.3.1(11.b), 13.11.2(3.a), 13.7.1(11.a), F.1(2.b)]
+
+In 6.3.1(3/1) and 6.3.1(14), "a pragma" should be "an aspect"; also delete the reference to
+Import and Export (these are separate aspects from the convention).
+
+In 3.6.2(11), replace "a pragma Convention(Fortran, ...);" with "aspect Convention specifying
+convention_identifier Fortran".
+
+Delete B.3.2(12); in B.3.2(10-11), add "with Convention => Intrinsic" to each declaration.
+
+In 13.7.2(4), delete the pragmas, in 13.7.2(3), add "with Convention => Intrinsic" to each function.
+
+In 13.7.1(11), delete the pragmas, in 13.7.1(7, 8, 10), add "with Convention => Intrinsic" to each function (7).
+
+In B.2(11.1/2), replace "pragma" by "aspect".
-[Editor's Note: Consider scrubbing AARM notes for "pragma Import", "pragma Export",
-and "pragma Convention". Should the dozen or so uses of pragma Convention (Intrinsic)
-in language-defined packages be changed??]
+In each of the following paragraphs, replace Pragma Convention (Intrinsic, xxx);
+with "with Convention => Intrinsic":
+13.9(3), 13.11.2(3), 3.9.2(18.2/2), 13.7(14), F.2(6).
+
Add a new clause to Annex J:
[Note: The subclauses will be rearranged in alphabetical order - at the last
@@ -1591,47 +1540,13 @@
C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for
the protected procedure handler_name to have the value of the given expression
[Redundant: as evaluated at object creation time].
-
-J.15.12 pragma Preelaborable_Initialization
-
- Syntax
-
- The form of a pragma Preelaborable_Initialization is as follows:
- pragma Preelaborable_Initialization (direct_name);
-
- Static Semantics
- A pragma Preelaborable_Initialization specifies that the
- Preelaborable_Initialization aspect (see 10.2.1) of the
- type denoted by its argument is True.
-
-[Editor's note: This is not a representation pragma since this is an operational
-aspect. Representation pragmas cannot be specified on partial views by 13.1(9).]
-
- Legality Rules
- A Preelaborable_Initialization pragma shall appear in the visible part of
- a package or generic package.
-
- If the pragma appears in the first list of basic_declarative_items of a
- package_specification, then the direct_name shall denote the first subtype
- of a composite type such that the Preelaborable_Initialization aspect of the
- type may be specified to be True, and the type shall be declared immediately
- within the same package as the pragma.
-
- If the pragma appears in a generic_formal_part, then the direct_name shall
- denote a composite generic formal type declared in the same
- generic_formal_part as the pragma such that the Preelaborable_Initialization
- aspect of the type may be specified to be True.
-
- In addition to the places where Legality Rules normally apply (see 12.3),
- these rules apply also in the private part of an instance of a generic unit.
-
-J.15.13 Shared variable pragmas
+J.15.12 Shared variable pragmas
Syntax
The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and
-Volatile_Components, and Independent_Components is as follows:
+Volatile_Components, and Independent_Components is as follows:
pragma Atomic(local_name);
@@ -1667,10 +1582,10 @@
The local_name of of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
-J.15.14 Interfacing pragmas
+J.15.13 Interfacing pragmas
An interfacing pragma is a representation pragma that is one of the pragmas Import,
-Export, or Convention. Their forms are as follows:
+Export, or Convention. Their forms are as follows:
pragma Import(
[Convention =>] convention_identifier, [Entity =>] local_name
@@ -1683,12 +1598,12 @@
pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);
For pragmas Import and Export, the argument for Link_Name shall not be given without
-the pragma_argument_identifier unless the argument for External_Name is given.
+the pragma_argument_identifier unless the argument for External_Name is given.
Name Resolution Rules
The expected type for a external_name_string_expression and a link_name_string_expression
-in an interfacing pragma is String.
+in an interfacing pragma is String.
Legality Rules
@@ -1697,7 +1612,7 @@
A pragma Import shall be the completion of a declaration.
The external_name_string_expression and link_name_string_expression of a pragma Import
-or Export shall be static.
+or Export shall be static.
The local_name of of each of these pragmas shall denote a declaration that may have
the similarly named aspect specified.
@@ -1720,12 +1635,10 @@
link_name_string_expression.
-*** Additional obsolescent pragmas here ***
-
Rearrange Annex K:
Annex K
@@ -4200,3 +4113,114 @@
****************************************************************
+From: John Barnes
+Sent: Thursday, April 7, 2011 5:48 AM
+
+Indeed this is huge and needs a quiet weekend in bed with a mild infection such
+as gout.
+
+However, on a quick skim through all seems OK. But I wonder why
+Preelaborable_Initialization is not left as a pragma like Pure etc. It sems to
+be the same sort of thing. Could confuse and puzzle users. Maybe it's just me
+and because I describe these things in the same section of my book.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 7, 2011 11:49 AM
+
+The strategy is that types, objects, and subprograms always use aspects rather
+than pragmas, while packages use pragmas. Thus P_I (which works on types) is
+described as an aspect. This should be a fairly easy rule to describe to your
+readers.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, April 8, 2011 6:13 PM
+
+GNAT will provide pragmas as well as aspects for all these kinds of things, so
+that they can be used in other than Ada 2012 mode, and in any case we implement
+aspects by translating them to the corresponding pragmas or attribute definition
+clauses.
+
+So in terms of actual use, it won't make a difference what the language decices
+here.
+
+****************************************************************
+
+From: John Barnes
+Sent: Monday, April 11, 2011 5:27 AM
+
+However, the recent phone meeting changed Preelaborable_Initialization to remain
+just as a pragma. Nothing to do with my book, but to do with views.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 12, 2011 11:05 AM
+
+Am I right in assuming that we prefer to say
+
+"the aspect Whatever" rather than "the Whatever aspect"?
+
+However, AI-229 has a few instances of the second. Particularly "the Pack
+aspect".
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Tuesday, April 12, 2011 11:15 AM
+
+I raised that question at the last phone meeting. My preference is for "aspect
+Whatever" but I was told that no single form has been adopted, and it was up to
+the ear of whoever wrote a particular paragraph. Personally I prefer the first
+form.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, April 12, 2011 11:26 AM
+
+I would vote for either "aspect Blah" or "the Blah aspect."
+Adding "the" in front of "aspect Blah" doesn't sound right to me.
+
+****************************************************************
+
+From: John Barnes
+Sent: Tuesday, April 12, 2011 11:57 AM
+
+Well the AI is riddled with all sorts of aspects. Some with the and some
+without. There are lots of "the aspect Blah".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 12, 2011 1:24 PM
+
+With AI05-0229-1, I preferred to say whatever made the least change to the
+existing wording (didn't want to introduce bugs with this rewording). When
+possible, that just meant changing "pragma" to "aspect". And there is no
+consistency about how pragmas are identified in text.
+
+Note that at least 4 people worded parts of this AI over about 2 months, and the
+wording being changed is in very many different styles, so the styles aren't
+that consistent. And in any case it has not been approved or reviewed yet, I
+still have to apply the changes from the phone meeting to it. So presume it will
+change some more (but not too drastically).
+
+P.S. I'd just as soon this AI got reviewed before I put it into the Standard, so
+if you are finding specific things to change, please point them out.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, April 13, 2011 8:15 AM
+
+> I would vote for either "aspect Blah" or "the Blah aspect."
+> Adding "the" in front of "aspect Blah" doesn't sound right to me.
+
+I agree with Tuck, and I don't see a need to force consistency, the choice of
+which of these sounds nicer depends on the circumstance.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent