CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/08/06 05:43:51 1.18
+++ ai05s/ai05-0229-1.txt 2011/08/13 04:50:41 1.19
@@ -1,7 +1,16 @@
-!standard 13.2(5) 11-08-05 AI05-0229-1/12
+!standard 1.1.3(17) 11-08-05 AI05-0229-1/12
+!standard 2.9(18)
!standard 2.8(29/2)
+!standard 3.6.2(11)
!standard 3.7(37/2)
+!standard 3.9(18.2/2)
+!standard 3.11(11)
+!standard 3.11.1(6)
+!standard 3.11.1(9)
!standard 4.8(15)
+!standard 6.1(20/2)
+!standard 6.3.1(3)
+!standard 6.3.1(14)
!standard 6.3.2(2)
!standard 6.3.2(3)
!standard 6.3.2(4)
@@ -15,19 +24,25 @@
!standard 6.5.1(4/2)
!standard 6.5.1(8/2)
!standard 6.5.1(10/2)
+!standard 7.4(2)
+!standard 7.4(8)
+!standard 7.4(14)
!standard 9.10(1)
+!standard 9.10(15)
!standard 10.1.4(7/2)
!standard 10.2.1(25)
!standard 10.2.1(26)
!standard 11.4.1(4/2)
!standard 11.5(7.2/2)
!standard 11.6(6)
+!standard 13.1(28/2)
!standard 13.2(1)
!standard 13.2(2)
!standard 13.2(3)
!standard 13.2(4)
!standard 13.2(5)
!standard 13.2(7)
+!standard 13.3(20)
!standard 13.3(38)
!standard 13.3(58)
!standard 13.3(60)
@@ -40,7 +55,16 @@
!standard 13.3(73)
!standard 13.3.1(0)
!standard 13.6(1)
+!standard 13.7(14)
+!standard 13.7.1(7)
+!standard 13.7.1(8)
+!standard 13.7.1(10)
+!standard 13.7.1(11)
+!standard 13.7.2(3)
+!standard 13.7.2(4)
!standard 13.8(13)
+!standard 13.9(3)
+!standard 13.11.2(3)
!standard 13.11.3(1)
!standard 13.11.3(2)
!standard 13.11.3(3)
@@ -64,6 +88,33 @@
!standard B.1(11)
!standard B.1(14)
!standard B.1(21)
+!standard B.1(22)
+!standard B.1(23)
+!standard B.1(25)
+!standard B.1(26)
+!standard B.1(27)
+!standard B.1(28)
+!standard B.1(29)
+!standard B.1(30)
+!standard B.1(31)
+!standard B.1(31)
+!standard B.1(32)
+!standard B.1(33)
+!standard B.1(38)
+!standard B.1(38.1/2)
+!standard B.1(39)
+!standard B.1(40)
+!standard B.1(41)
+!standard B.1(42)
+!standard B.1(43)
+!standard B.1(44)
+!standard B.1(45)
+!standard B.1(46)
+!standard B.1(48)
+!standard B.1(51)
+!standard B.2(10.1/2)
+!standard B.2(11.1/2)
+!standard B.3(1/2)
!standard B.3(23)
!standard B.3(33)
!standard B.3(34)
@@ -71,6 +122,13 @@
!standard B.3(39.6/2)
!standard B.3(39.14/2)
!standard B.3(39.15/2)
+!standard B.3(60.13/1)
+!standard B.3(61/1)
+!standard B.3(62)
+!standard B.3.1(1)
+!standard B.3.2(10)
+!standard B.3.2(11)
+!standard B.3.2(12)
!standard B.3.3(1/2)
!standard B.3.3(2/2)
!standard B.3.3(3/2)
@@ -78,11 +136,23 @@
!standard B.3.3(5/2)
!standard B.3.3(6/2)
!standard B.3.3(29/2)
+!standard B.3.3(31/2)
+!standard B.4(1)
!standard B.4(12)
!standard B.4(16)
!standard B.4(20)
!standard B.4(29)
+!standard B.4(92)
+!standard B.4(99)
+!standard B.4(106)
+!standard B.4(107)
+!standard B.4(115)
+!standard B.5(1)
!standard B.5(12)
+!standard B.5(20)
+!standard B.5(30)
+!standard C.1(4)
+!standard C.1(8)
!standard C.3.1(1)
!standard C.3.1(2)
!standard C.3.1(3)
@@ -102,6 +172,18 @@
!standard C.3.2(21)
!standard C.3.2(24)
!standard C.3.2(28)
+!standard C.6(1)
+!standard C.6(2)
+!standard C.6(3)
+!standard C.6(4)
+!standard C.6(5)
+!standard C.6(6)
+!standard C.6(7/2)
+!standard C.6(8)
+!standard C.6(9)
+!standard C.6(10)
+!standard C.6(13)
+!standard C.6(14)
!standard C.6(21)
!standard D.1(2)
!standard D.1(3)
@@ -116,6 +198,7 @@
!standard D.1(17)
!standard D.1(18)
!standard D.1(19)
+!standard D.2.4(11/2)
!standard D.2.6(2/2)
!standard D.2.6(3/2)
!standard D.2.6(4/2)
@@ -128,6 +211,7 @@
!standard D.3(8/2)
!standard D.3(10/2)
!standard D.3(11/2)
+!standard D.5.2(6/2)
!standard D.13(5/2)
!standard D.16(0)
!standard E.2.3(13)
@@ -142,6 +226,9 @@
!standard E.4.1(7)
!standard E.4.1(8)
!standard E.4.1(9)
+!standard F(7)
+!standard F.2(6)
+!standard G(7)
!standard J.15(0)
!standard J.15.1(0)
!standard J.15.2(0)
@@ -230,7 +317,19 @@
(unlike the typical obsolescent feature) and rejecting them could be a significant
portability problem for existing code.
+Modify 1.1.3(17):
+An implementation conforming to this International Standard may provide additional
+{aspects, }attributes, library units, and pragmas. However, it shall not provide
+any {aspect, }attribute, library unit, or pragma having the same name as an
+{aspect, }attribute, library unit, or pragma (respectively) specified in a
+Specialized Needs Annex unless the provided construct is either as specified
+in the Specialized Needs Annex or is more limited in capability than that required
+by the Annex. A program that attempts to use an unsupported capability of an Annex
+shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+
+
Changes for individual pragmas:
Representation pragmas: (Covered by the general wording).
@@ -424,26 +523,38 @@
Independent_Components, Volatile, Volatile_Components: (the pragmas are to be
obsolescent)
+In C.6(1), replace "pragmas" with "aspects".
Rewrite C.6(2-8)) as follows:
Static Semantics
-For an object declaration, a component declaration, or a full type declaration,
-the following representation aspects can be specified: Atomic, Volatile,
-and Independent.
-
-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, a component_declaration, or a full_type_declaration,
+the following representation aspects may be specified:
+ Atomic
+ The type of aspect Atomic is Boolean.
+ Independent
+ The type of aspect Independent is Boolean.
+ Volatile
+ The type of aspect Volatile is Boolean.
+
+For a full_type_declaration of an array type (including the anonymous type of
+an object_declaration of an anonymous array object), the following representation
+aspects may be specified:
+ Atomic_Components
+ The type of aspect Atomic_Components is Boolean.
+ Volatile_Components
+ The type of aspect Volatile_Components is Boolean.
+
+For a full_type_declaration (including the anonymous type of
+an object_declaration of an anonymous array object), the following representation
+aspect may be specified:
+ Independent_Components
+ The type of aspect Independent_Components is Boolean.
-The type of these aspects is Boolean. If any of these aspects are directly
+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.
+(including by inheritance), each of these aspects is 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,
@@ -458,6 +569,11 @@
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.
+When True, the aspects Independent and Independent_Components *specify as independently
+addressable* the named object or component(s), or in the case of a type,
+all objects of that type. All atomic objects are considered to be specified as
+independently addressable.
+
Delete C.6(9/3) [Now in Annex J.]
Replace C.6(10) with the following two paragraphs:
@@ -468,17 +584,18 @@
[This rule is needed to replace the resolution rules of C.6(9/3) for items
not previously included. We don't need a rule for components as there is no
way to write an inherited component_declaration. We intend that all components
-and types to have the "regular" aspects. - RLB]
+and types have the "regular" aspects, it's just not possible to change them
+for some kinds of types. - RLB]
-It is illegal to specify the aspect Atomic or Atomic_Components for an object
-or type if the implementation cannot support the indivisible reads and writes
-required by the aspect (see below).
+It is illegal to specify the aspect Atomic or Atomic_Components to have the value
+True for an object or type if the implementation cannot support the indivisible
+reads and writes required by the aspect (see below).
Replace C.6(13):
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.
+directly specified to have the value True for a stand-alone constant object,
+then the aspect Import shall also be specified as True 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
@@ -497,13 +614,12 @@
Delete C.6(14) [Now in Annex J.]
-Replace C.6(14.1/3):
+Delete C.6(14.1/3) (moved above).
-When True, the aspects Independent and Independent_Components *specify as independently
-addressable* the named object or component(s), or in the case of a type,
-all objects of that type. All atomic objects are considered to be specified as
-independently addressable.
+Replace 9.10(15) with:
+Aspect Atomic or aspect Atomic_Components may also be specified to ensure that
+certain reads and updates are sequential — see C.6.
===pragma Asynchronous: (the pragma is to be obsolescent)
@@ -1200,10 +1316,9 @@
For an imported or exported subprogram, the result and parameter types
shall each be compatible with the specified Convention aspect, if any.
- The Boolean_expression (if any) used to directly specify an Import or
- export aspect shall be a static expression.
- The string_expression used to directly specify an External_Name or
- Link_Name aspect, and the string_expression of a pragma Linker_Options,
+ The aspect_definition (if any) used to directly specify an Import,
+ Export, External_Name, or Link_Name aspect shall be a static expression.
+ The string_expression of a pragma Linker_Options,
shall be static. An External_Name or Link_Name aspect shall be specified
only for an entity that is either imported or exported.
@@ -1214,17 +1329,17 @@
type, it represents the calling convention of designated subprograms.
In addition:
- A True Import aspect indicates that the entity is defined externally
- (that is, outside the Ada program).
- This aspect is never inherited; if not directly specified, the Import
- aspect is False.
-
- A True Export aspect indicates that the entity is used externally.
- This aspect is never inherited; if not directly specified, the Import
- aspect is False.
+ * A True Import aspect indicates that the entity is defined externally
+ (that is, outside the Ada program).
+ This aspect is never inherited; if not directly specified, the Import
+ aspect is False.
+
+ * A True Export aspect indicates that the entity is used externally.
+ This aspect is never inherited; if not directly specified, the Export
+ aspect is False.
- For an entity with a True Import or Export aspect, an external name,
- link name, or both may also be specified.
+ * For an entity with a True Import or Export aspect, an external name,
+ link name, or both may also be specified.
An external name is a string value for the name used by a foreign
language program either for an entity that an Ada program imports, or
@@ -1273,12 +1388,12 @@
and subsequent time they are called.
Automatic elaboration of preelaborated packages should be provided
- when Export is specified.
+ when specifying Export as True is supported.
For each supported convention L other than Intrinsic, an
- implementation should support Import and Export specification for
- objects of L-compatible types and for subprograms, and Convention
- specification for L-eligible types and for subprograms, presuming the
+ implementation should support specifying the Import and Export aspects for
+ objects of L-compatible types and for subprograms, and the Convention
+ aspect for L-eligible types and for subprograms, presuming the
other language has corresponding features. Specifying the Convention
aspect need not be supported for scalar types.
@@ -1300,8 +1415,9 @@
access-to-subprogram type and the specific subprogram(s) to which
'Access is applied.
- 4 It is illegal to specify that both the Import and Export aspects of
- an entity are true.
+ [Editor's Note: Note 4 is deleted as we have a Legality Rule that
+ says essentially the same thing; no need to repeat it. Note 5 is deleted
+ as it only applies to the pragmas (now in Annex J) and not to the aspects.]
6 See also 13.8, “Machine Code Insertions”.
@@ -1328,23 +1444,69 @@
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
+An implementation need not support specifying the Convention aspect with convention_identifier C
+in the following cases:
+* 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.
+* for a function with an unconstrained array result subtype;
+* 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)]
+
+Replace 3.11(11) by:
+
+For a call to a protected operation of a protected type (that has a body — no check is performed
+if the protected type is imported - see B.1), a check is made that the protected_body
+is already elaborated. This check and the evaluations of any actual parameters of the call are done
+in an arbitrary order.
+
+Modify 3.11.1(6):
-In 6.3.1(3/1) and 6.3.1(14), "a pragma" should be "an aspect"; also delete the reference to
+An implicit declaration shall not have a completion. For any explicit declaration that is specified
+to require completion, there shall be a corresponding explicit completion{, unless the declared
+entity is imported (see B.1)}.
+
+Replace 3.11.1(9) by:
+
+96 Completions are in principle allowed for any kind of explicit declaration. However, for
+some kinds of declaration, the only allowed completion is an implementation-defined pragma,
+and implementations are not required to have any such pragmas.
+
+Replace the first sentence of 6.1(20/3) with:
+
+A subprogram_declaration or a generic_subprogram_declaration requires a completion
+[Redundant: unless the Import aspect (see B.1) is True for the declaration; the completion will be
+a body or a renaming_declaration (see 8.5)].
+
+AARM Proof: When the Import aspect is True for any entity, no completion is allowed (see B.1).
+
+In 6.3.1(3) 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).
+Replace the last sentence of 7.4(2):
+
+A deferred constant declaration requires a completion, which shall be a full constant declaration
+(called the full declaration of the deferred constant), Redundant[ unless the Import aspect (see B.1)
+is True for the deferred constant declaration.]
+
+AARM Proof: When the Import aspect is True for any entity, no completion is allowed (see B.1).
+
+Modify 7.4(8):
+
+A deferred constant declaration {for which the Import aspect is True}[that is completed by a
+pragma Import] need not appear in the visible part of a package_specification, and has no full
+constant declaration.
+
+Replace 7.4(14) with:
+
+CPU_Identifier : constant String(1..8)
+ with Import => True, Convention => Assembler Link_Name => "CPU_ID";
+ -- see B.1
+
In 3.6.2(11), replace "a pragma Convention(Fortran, ...);" with "aspect Convention specifying
convention_identifier Fortran".
@@ -1356,9 +1518,11 @@
In B.2(11.1/2), replace "pragma" by "aspect".
+In B.2(10.1/2), add "aspect, " in front to "attribute" (two places).
+
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).
+13.9(3), 13.11.2(3), 3.9(18.2/2), 13.7(14), F.2(6).
Add a new clause to Annex J:
@@ -1528,7 +1692,13 @@
The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).
-A pragma Import shall be the completion of a declaration.
+A pragma Import shall be the completion of a declaration. Notwithstanding any rule to the
+contrary, a pragma Import may serve as the completion of any kind of (explicit) declaration
+if supported by an implementation for that kind of declaration. If a completion is a pragma
+Import, then it shall appear in the same declarative_part, package_specification, task_definition
+or protected_definition as the declaration. For a library unit, it shall appear in the same
+compilation, before any subsequent compilation_units other than pragmas. If the local_name
+denotes more than one entity, then the pragma Import is the completion of all of them.
The external_name_string_expression and link_name_string_expression of a pragma Import
or Export shall be static.
@@ -1791,6 +1961,11 @@
K.1 Language-Defined Aspects
+This clause summarizes the definitions given elsewhere
+of the language-defined aspects. Aspects are properties of entities that can
+be specified by the Ada program; unless otherwise specified below, aspects
+can be specified using an aspect_specification.
+
...[etc]
Precondition: Specifies a condition that must hold true in order to call a given
@@ -1801,6 +1976,12 @@
K.2 Language-Defined Attributes
+The {clause}[annex] summarizes the definitions given elsewhere
+of the language-defined attributes. {Attributes are properties of entities
+that can be queried by an Ada program.}
+
+
+
...[entire contents of old Annex K goes here.]
@@ -1997,6 +2178,37 @@
an aspect).
+!corrigendum 1.1.3(17)
+
+@drepl
+An implementation conforming to this International Standard may provide additional
+attributes, library units, and pragmas. However, it shall not provide
+any attribute, library unit, or pragma having the same name as an
+attribute, library unit, or pragma (respectively) specified in a
+Specialized Needs Annex unless the provided construct is either as specified
+in the Specialized Needs Annex or is more limited in capability than that required
+by the Annex. A program that attempts to use an unsupported capability of an Annex
+shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+@dby
+An implementation conforming to this International Standard may provide additional
+aspects, attributes, library units, and pragmas. However, it shall not provide
+any aspect, attribute, library unit, or pragma having the same name as an
+aspect, attribute, library unit, or pragma (respectively) specified in a
+Specialized Needs Annex unless the provided construct is either as specified
+in the Specialized Needs Annex or is more limited in capability than that required
+by the Annex. A program that attempts to use an unsupported capability of an Annex
+shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+
+
+!corrigendum 2.8(18)
+
+@drepl
+@xbullet<A pragma used to complete a declaration, such as a pragma Import;>
+@dby
+@xbullet<A pragma used to complete a declaration;>
+
!corrigendum 2.8(29/2)
@drepl
@@ -2011,6 +2223,20 @@
@b<pragma> Assert(Exists(File_Name), Message => "Nonexistent file"); --@ft<@i< assert file exists>>>
+!corrigendum 3.6.2(11)
+
+@drepl
+An implementation should normally represent multidimensional arrays in row-major order,
+consistent with the notation used for multidimensional array aggregates (see 4.3.3).
+However, if a @b<pragma> Convention(Fortran, ...) applies to a multidimensional
+array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+@dby
+An implementation should normally represent multidimensional arrays in row-major order,
+consistent with the notation used for multidimensional array aggregates (see 4.3.3).
+However, if convention Fortran is specified for a multidimensional
+array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+
+
!corrigendum 3.7(37/2)
@drepl
@@ -2029,6 +2255,68 @@
@b<end> Worker;>
+!corrigendum 3.9(18.2/2)
+
+@drepl
+@xcode<@b<generic>
+ @b<type> T (<@>) @b<is abstract tagged limited private>;
+ @b<type> Parameters (<@>) @b<is limited private>;
+ @b<with function> Constructor (Params : @b<not null access> Parameters)
+ @b<return> T @b<is abstract>;
+@b<function> Ada.Tags.Generic_Dispatching_Constructor
+ (The_Tag : Tag;
+ Params : @b<not null access> Parameters) @b<return> T'Class;
+@b<pragma> Preelaborate(Generic_Dispatching_Constructor);
+@b<pragma> Convention(Intrinsic, Generic_Dispatching_Constructor);>
+@dby
+@xcode<@b<generic>
+ @b<type> T (<@>) @b<is abstract tagged limited private>;
+ @b<type> Parameters (<@>) @b<is limited private>;
+ @b<with function> Constructor (Params : @b<not null access> Parameters)
+ @b<return> T @b<is abstract>;
+@b<function> Ada.Tags.Generic_Dispatching_Constructor
+ (The_Tag : Tag;
+ Params : @b<not null access> Parameters) @b<return> T'Class
+ @b<with> Convention => Intrinsic;
+@b<pragma> Preelaborate(Generic_Dispatching_Constructor);>
+
+
+!corrigendum 3.11(11)
+
+@drepl
+@xbullet<For a call to a protected operation of a protected type (that has a body — no check is performed
+if a @fa<pragma> Import applies to the protected type), a check is made that the @fa<protected_body>
+is already elaborated. This check and the evaluations of any actual parameters of the call are done
+in an arbitrary order.>
+@dby
+@xbullet<For a call to a protected operation of a protected type (that has a body — no check is performed
+if the protected type is imported - see B.1), a check is made that the @fa<protected_body>
+is already elaborated. This check and the evaluations of any actual parameters of the call are done
+in an arbitrary order.>
+
+
+!corrigendum 3.11.1(6)
+
+@drepl
+An implicit declaration shall not have a completion. For any explicit declaration that is specified
+to @i<require completion>, there shall be a corresponding explicit completion.
+@dby
+An implicit declaration shall not have a completion. For any explicit declaration that is specified
+to @i<require completion>, there shall be a corresponding explicit completion, unless the declared
+entity is imported (see B.1).
+
+!corrigendum 3.11.1(9)
+
+@drepl
+@s9<96 Completions are in principle allowed for any kind of explicit declaration. However, for
+some kinds of declaration, the only allowed completion is a pragma Import, and implementations
+are not required to support pragma Import for every kind of entity.>
+@dby
+@s9<96 Completions are in principle allowed for any kind of explicit declaration. However, for
+some kinds of declaration, the only allowed completion is an implementation-defined pragma,
+and implementations are not required to have any such pragmas.>
+
+
!corrigendum 4.8(15)
@drepl
@@ -2038,6 +2326,44 @@
@s9<27 Implementations are permitted, but not required, to provide garbage collection.>
+!corrigendum 6.1(20/2)
+
+@drepl
+A @fa<subprogram_declaration> or a @fa<generic_subprogram_declaration> requires
+a completion: a body, a @fa<renaming_declaration> (see 8.5), or a @fa<pragma>
+Import (see B.1). A completion is not allowed for an
+@fa<abstract_subprogram_declaration> (see 3.9.3) or a
+@fa<null_procedure_declaration> (see 6.7).
+@dby
+A @fa<subprogram_declaration> or a @fa<generic_subprogram_declaration> requires
+a completion: unless the Import aspect (see B.1) is True for the declaration; the
+completion will be a body or a @fa<renaming_declaration> (see 8.5).
+A completion is not allowed for an
+@fa<abstract_subprogram_declaration> (see 3.9.3), a
+@fa<null_procedure_declaration> (see 6.7), or an
+@fa<expression_function_declaration> (see 6.8).
+
+
+!corrigendum 6.3.1(3)
+
+@drepl
+@xbullet<The default calling convention for any subprogram not listed below is @i<Ada>.
+A @fa<pragma> Convention, Import, or Export may be used to override the default
+calling convention (see B.1).>
+@dby
+@xbullet<The default calling convention for any subprogram not listed below is @i<Ada>.
+The Convention aspect may be specified to override the default
+calling convention (see B.1).>
+
+!corrigendum 6.3.1(14)
+
+@drepl
+Of these four conventions, only Ada and Intrinsic are allowed as a @I<convention_>identifier
+in a @fa<pragma> Convention, Import, or Export.
+@dby
+Of these four conventions, only Ada and Intrinsic are allowed as a @I<convention_>identifier
+in the specification of aspect Convention.
+
!corrigendum 6.3.2(2)
@ddel
@@ -2168,6 +2494,51 @@
@b<with> No_Return =@> True;
--@ft<@i< Inform compiler and reader that procedure never returns normally>>>
+
+!corrigendum 7.4(2)
+
+@drepl
+A @i<deferred constant declaration> is an @fa<object_declaration>
+with the reserved word @b<constant> but no initialization expression.
+The constant declared by a deferred constant declaration is called
+a @i<deferred constant>.
+A deferred constant declaration requires a completion,
+which shall be a full constant declaration
+(called the @i<full declaration> of the deferred constant),
+or a @fa<pragma> Import (see Annex B).
+@dby
+A @i<deferred constant declaration> is an @fa<object_declaration>
+with the reserved word @b<constant> but no initialization expression.
+The constant declared by a deferred constant declaration is called
+a @i<deferred constant>.
+A deferred constant declaration requires a completion, which shall be a
+full constant declaration (called the @i<full declaration> of the deferred
+constant), unless the Import aspect (see B.1)
+is True for the deferred constant declaration.
+
+!corrigendum 7.4(8)
+
+@drepl
+A deferred constant declaration that is completed by a @fa<pragma> Import need
+not appear in the visible part of a @fa<package_specification>,
+and has no full constant declaration.
+@dby
+A deferred constant declaration for which the Import aspect is True need not
+appear in the visible part of a @fa<package_specification>, and has no full
+constant declaration.
+
+!corrigendum 7.4(14)
+
+@drepl
+@xcode<CPU_Identifier : @b<constant> String(1..8);
+@b<pragma> Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID");
+ --@i<@ft< see B.1>>>
+@dby
+@xcode<CPU_Identifier : @b<constant> String(1..8)
+ @b<with> Import => True, Convention => Assembler, Link_Name => "CPU_ID";
+ --@i<@ft< see B.1>>>
+
+
!corrigendum 9.10(1)
!comment This contains the AI-0009-1 and AI-0201-1 changes as well.
@@ -2192,6 +2563,14 @@
record layout, Component_Size, Pack, Atomic, or convention, in which case
it is unspecified whether the parts are independently addressable.
+!corrigendum 9.10(15)
+
+@drepl
+A @fa<pragma> Atomic or Atomic_Components may also be used to ensure that
+certain reads and updates are sequential — see C.6.
+@dby
+Aspect Atomic or aspect Atomic_Components may also be specified to ensure
+that certain reads and updates are sequential — see C.6.
!corrigendum 10.1.4(7/2)
@@ -2324,7 +2703,20 @@
disrupted by the raising of the exception, causing the object or its parts to become
abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
+!corrigendum 13.1(28/2)
+
+@dinsa
+For purposes of these rules, the determination of whether a representation item
+applied to a type @i<could cause> an object to have some property is based
+solely on the properties of the type itself, not on any available information
+about how the type is used. In particular, it presumes that minimally aligned
+objects of this type might be declared at some point.
+@dinst
+@s9<NOTES@hr
+1 Aspects that can be specified are defined throughout this International Standard,
+ and are summarized in K.1.>
+
!corrigendum 13.2(0)
@drepl
@@ -2360,6 +2752,19 @@
!comment %% 13.2(5) and 13.2(7) need changes here.
+
+!corrigendum 13.3(20)
+
+@drepl
+@s9<2 The specification of a link name in a pragma Export (see B.1) for a subprogram or
+object is an alternative to explicit specification of its link-time address, allowing a
+link-time directive to place the subprogram or object within memory.>
+@dby
+@s9<2 The specification of a link name with the Link_Name aspect (see B.1) for a subprogram or
+object is an alternative to explicit specification of its link-time address, allowing a
+link-time directive to place the subprogram or object within memory.>
+
+
!corrigendum 13.3(38)
@drepl
@@ -2450,7 +2855,15 @@
and the other does not, then explicit conversion can be used to pack or unpack an array.
+!comment %% 13.7(14) needs changes here.
+
+!comment %% 13.7.1(7), 13.7.1(8), 13.7.1(10), and 13.7.1(11) need changes here.
+
+
+!comment %% 13.7.2(3) and 13.7.2(4) need changes here.
+
+
!corrigendum 13.8(13)
@drepl
@@ -2461,6 +2874,13 @@
@b<procedure> Set_Mask
@b<with> Inline;>
+
+!comment %% 13.9(3) needs change here.
+
+
+!comment %% 13.11.2(3) needs change here.
+
+
!corrigendum 13.11.3(1)
@ddel
@@ -2589,14 +3009,270 @@
The expected type for the @i<string_>@fa<expression> in pragma Linker_Options, is
String.
-!comment %% B.1(11), B.1(14), and B.1(21) need changes here.
+!comment %% B.1(11), B.1(14), B.1(21), and B.1(22) need changes here.
-!comment %% More B.1(xx) need changes here.
+!corrigendum B.1(23)
+@drepl
+An entity specified as the Entity argument to a @fa<pragma> Import (or @fa<pragma> Export) is said
+to be @i<imported> (respectively, @i<exported>).
+@dby
+An entity with a True Import aspect (or Export aspect) is said to be
+@i<imported> (respectively, @i<exported>). An entity shall not be both imported
+and exported.
-!comment %% B.3(23), B.3(33), B.3(34), B.3(39.5/2), B.3(39.6/2), B.3(39.14/2), and B.3(39.15/2) need changes here.
+!corrigendum B.1(25)
+@drepl
+The type of an imported or exported object shall be compatible with the
+convention specified in the corresponding pragma.
+@dby
+The type of an imported or exported object shall be compatible with
+the specified Convention aspect, if any.
+!corrigendum B.1(26)
+
+@drepl
+For an imported or exported subprogram, the result and parameter types
+shall each be compatible with the convention specified in the corresponding
+pragma.
+@dby
+For an imported or exported subprogram, the result and parameter types
+shall each be compatible with the specified Convention aspect, if any.
+
+!corrigendum B.1(27)
+
+@drepl
+The external name and link name @i<string_>@fa<expression>s of a @fa<pragma>
+Import or Export, and the @i<string_>@fa<expression> of a @fa<pragma>
+Linker_Options, shall be static.
+@dby
+The @fa<aspect_definition> (if any) used to directly specify an Import,
+Export, External_Name, or Link_Name aspect shall be a static expression.
+The @i<string_>@fa<expression> of a pragma Linker_Options
+shall be static. An External_Name or Link_Name aspect shall be specified
+only for an entity that is either imported or exported.
+
+!corrigendum B.1(28)
+
+@ddel
+Import, Export, and Convention @fa<pragma>s are representation pragmas that specify the
+convention aspect of representation. In addition, Import and Export @fa<pragma>s specify
+the imported and exported aspects of representation, respectively.
+
+!corrigendum B.1(29)
+
+@ddel
+An interfacing pragma is a program unit pragma when applied to a program unit (see 10.1.5).
+
+!corrigendum B.1(30)
+
+@drepl
+An interfacing pragma defines the convention of the entity denoted by the @fa<local_name>.
+The convention represents the calling convention or representation convention of the entity.
+For an access-to-subprogram type, it represents the calling convention of designated subprograms.
+In addition:
+@dby
+The Convention aspect represents the calling convention or
+representation convention of the entity. For an access-to-subprogram
+type, it represents the calling convention of designated subprograms.
+In addition:
+
+!corrigendum B.1(31)
+
+@drepl
+@xbullet<A @fa<pragma> Import specifies that the entity is defined externally (that is,
+outside the Ada program).>
+@dby
+@xbullet<A True Import aspect indicates that the entity is defined externally
+(that is, outside the Ada program). This aspect is never inherited; if not directly
+specified, the Import aspect is False.>
+
+!corrigendum B.1(32)
+
+@drepl
+@xbullet<A @fa<pragma> Export specifies that the entity is used externally.>
+@dby
+@xbullet<A True Export aspect indicates that the entity is used externally.
+This aspect is never inherited; if not directly specified, the Export
+aspect is False.>
+
+!corrigendum B.1(33)
+
+@drepl
+@xbullet<A @fa<pragma> Import or Export optionally specifies an entity's external name,
+link name, or both.>
+@dby
+@xbullet<For an entity with a True Import or Export aspect, an external name,
+link name, or both may also be specified.>
+
+!corrigendum B.1(38)
+
+@drepl
+Notwithstanding what this International Standard says elsewhere, the elaboration of a
+declaration denoted by the @fa<local_name> of a @fa<pragma> Import does not create
+the entity. Such an elaboration has no other effect than to allow the defining name
+to denote the external entity.
+@dby
+Notwithstanding what this International Standard says elsewhere, the
+elaboration of a declaration with a True Import aspect
+does not create the entity. Such an elaboration has no other
+effect than to allow the defining name to denote the external entity.
+
+!corrigendum B.1(38.1/2)
+
+@drepl
+It is the programmer's responsibility to ensure that the use of interfacing pragmas
+does not violate Ada semantics; otherwise, program execution is erroneous.
+@dby
+It is the programmer's responsibility to ensure that the use of
+interfacing aspects does not violate Ada semantics; otherwise,
+program execution is erroneous.
+
+!corrigendum B.1(39)
+
+@drepl
+If an implementation supports pragma Export to a given language, then it should also
+allow the main subprogram to be written in that language. It should support some mechanism
+for invoking the elaboration of the Ada library units included in the system, and for
+invoking the finalization of the environment task. On typical systems, the recommended
+mechanism is to provide two subprograms whose link names are "adainit" and "adafinal".
+Adainit should contain the elaboration code for library units. Adafinal should contain
+the finalization code. These subprograms should have no effect the second and subsequent
+time they are called.
+@dby
+If an implementation supports Export to a given language, then
+it should also allow the main subprogram to be written in that
+language. It should support some mechanism for invoking the
+elaboration of the Ada library units included in the system, and for
+invoking the finalization of the environment task. On typical
+systems, the recommended mechanism is to provide two subprograms
+whose link names are "adainit" and "adafinal". Adainit should contain
+the elaboration code for library units. Adafinal should contain the
+finalization code. These subprograms should have no effect the second
+and subsequent time they are called.
+
+!corrigendum B.1(40)
+
+@drepl
+Automatic elaboration of preelaborated packages should be provided when @fa<pragma>
+Export is supported.
+@dby
+Automatic elaboration of preelaborated packages should be provided
+when specifying Export as True is supported.
+
+!comment %% B.1(41), B.1(42), B.1(43), B.1(44), B.1(45), B.1(46), B.1(48), and B.1(51) need changes here.
+
+
+!corrigendum B.2(10.1/2)
+
+@drepl
+Support for interfacing to any foreign language is optional. However, an implementation
+shall not provide any attribute, library unit, or pragma having the same name as an attribute,
+library unit, or pragma (respectively) specified in the following clauses of this Annex unless
+the provided construct is either as specified in those clauses or is more limited in capability
+than that required by those clauses. A program that attempts to use an unsupported capability
+of this Annex shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+@dby
+Support for interfacing to any foreign language is optional. However, an implementation
+shall not provide any aspect, attribute, library unit, or pragma having the same name as an
+aspect, attribute, library unit, or pragma (respectively) specified in the following clauses of
+this Annex unless
+the provided construct is either as specified in those clauses or is more limited in capability
+than that required by those clauses. A program that attempts to use an unsupported capability
+of this Annex shall either be identified by the implementation before run time or shall raise
+an exception at run time.
+
+!corrigendum B.2(11.1/2)
+
+@drepl
+A child package of package Interfaces with the name of a convention may be provided independently
+of whether the convention is supported by the pragma Convention and vice versa. Such a child
+package should contain any declarations that would be useful for interfacing to the language
+(implementation) represented by the convention. Any declarations useful for interfacing to
+any language on the given hardware architecture should be provided directly in Interfaces.
+@dby
+A child package of package Interfaces with the name of a convention may be provided independently
+of whether the convention is supported by the Convention aspect and vice versa. Such a child
+package should contain any declarations that would be useful for interfacing to the language
+(implementation) represented by the convention. Any declarations useful for interfacing to
+any language on the given hardware architecture should be provided directly in Interfaces.
+
+
+!comment %% B.3(1/2), B.3(23), B.3(33), B.3(34), B.3(39.5/2), B.3(39.6/2), B.3(39.14/2), and B.3(39.15/2) need changes here.
+
+!corrigendum B.3(60.13/1)
+
+@drepl
+A Convention pragma with @i<convention_>@fa<identifier> C_Pass_By_Copy shall only be applied to a type.
+@dby
+The Convention aspect with @i<convention_>@fa<identifier> C_Pass_By_Copy shall only be
+specified for a type.
+
+!corrigendum B.3(61/1)
+
+@drepl
+An implementation shall support pragma Convention with a C @i<convention_>@fa<identifier> for a
+C-eligible type (see B.1). An implementation shall support pragma Convention with a C_Pass_By_Copy
+@i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
+@dby
+An implementation shall support specifying aspect Convention with a C @i<convention_>@fa<identifier>
+for a C-eligible type (see B.1). An implementation shall support specifying aspect Convention
+with a C_Pass_By_Copy @i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
+
+!corrigendum B.3(62)
+
+@dinsa
+An implementation may provide additional declarations in the C interface packages.
+@dinss
+An implementation need not support specifying the Convention aspect with
+@i<convention_>@fa<identifier> C in the following cases:
+
+@xbullet<for a subprogram that has a parameter of an
+unconstrained array subtype, unless the Import aspect has the value True for the subprogram;>
+
+@xbullet<for a function with an unconstrained array result subtype;>
+
+@xbullet<for an object whose nominal subtype is an unconstrained array subtype.>
+
+!corrigendum B.3(78)
+
+@drepl
+@xcode< -- @i<@ft<Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
+ @b<procedure> Strcpy (Target : @b<out> C.char_array;
+ Source : @b<in> C.char_array);>
+@dby
+@xcode< -- @i<@ft<Note: since the C function's return value is of no interest, the Ada interface is a procedure>>
+ @b<procedure> Strcpy (Target : @b<out> C.char_array;
+ Source : @b<in> C.char_array)
+ @b<with> Import => True, Convention => C, External_Name => "strcpy";>
+
+!corrigendum B.3(79)
+
+@ddel
+@xcode< @b<pragma> Import(C, Strcpy, "strcpy");
+
+!corrigendum B.3.1(1)
+
+@drepl
+The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to
+allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
+corresponds to a common use of “char *” in C programs, and an object of this type can be passed
+to a subprogram to which pragma Import(C,...) has been applied, and for which “char *” is the
+type of the argument of the C function.
+@dby
+The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to
+allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
+corresponds to a common use of “char *” in C programs, and an object of this type can be passed
+to a subprogram to which @ft<@b<with> Import => True, Convention => C> has been specified, and for
+which “char *” is the type of the argument of the C function.
+
+
+
+!comment %% B.3.2(10), B.3.2(11), and B.3.2(12) need changes here.
+
+
!corrigendum B.3.3(0)
@drepl
@@ -2612,11 +3288,59 @@
An implementation may require that @fa<pragma> Controlled
be specified for the type of an access subcomponent of an unchecked union type.
+!corrigendum B.3.3(31/2)
+
+@drepl
+@s9<@xcode<@s9< @b<type> T (Flag : Boolean := False) @b<is>
+ @b<record>
+ @b<case> Flag @b<is>
+ @b<when> False =@>
+ F1 : Float := 0.0;
+ @b<when> True =@>
+ F2 : Integer := 0;
+ @b<end case>;
+ @b<end record>;
+ @b<pragma> Unchecked_Union (T);>
+@dby
+@s9<@xcode<@s9< @b<type> T (Flag : Boolean := False) @b<is>
+ @b<record>
+ @b<case> Flag @b<is>
+ @b<when> False =@>
+ F1 : Float := 0.0;
+ @b<when> True =@>
+ F2 : Integer := 0;
+ @b<end case>;
+ @b<end record>
+ @b<with> Unchecked_Union;>
+
+
+!comment %% B.4(1), B.4(12), B.4(16), B.4(20), B.4(29), B.4(92), B.4(99), B.4(106), B.4(107), and B.4(115) need changes here.
-!comment %% B.4(12), B.4(16), B.4(20), and B.4(29) need changes here.
-!comment %% B.5(12) needs changes here.
+!comment %% B.5(1), B.5(12), B.5(20), and B.5(30) need changes here.
+
+!corrigendum C.1(4)
+
+@drepl
+The interfacing pragmas (see Annex B) should support interface to assembler; the default assembler
+should be associated with the convention identifier Assembler.
+@dby
+The interfacing aspects (see Annex B) should support interface to assembler; the default assembler
+should be associated with the convention identifier Assembler.
+
+!corrigendum C.1(8)
+
+@drepl
+The implementation shall document the subprogram calling conventions associated with the convention
+identifiers available for use with the interfacing pragmas (Ada and Assembler, at a minimum),
+including register saving, exception propagation, parameter passing, and function value returning.
+@dby
+The implementation shall document the subprogram calling conventions associated with the convention
+identifiers available for use with the Convention aspect (Ada and Assembler, at a minimum),
+including register saving, exception propagation, parameter passing, and function value returning.
+
+
!comment %% C.3.1(1), C.3.1(2), C.3.1(3), C.3.1(4), C.3.1(5), and C.3.1(6) need changes here.
!corrigendum C.3.1(7/2)
@@ -2781,7 +3505,87 @@
!comment %% C.3.2(28) needs changes here.
+!corrigendum C.6(1)
+
+@drepl
+This clause specifies representation pragmas that control the use of shared variables.
+@dby
+This clause defines representation aspects that control the use of shared variables.
+
+!corrigendum C.6(2)
+
+@ddel
+The form for pragmas Atomic, Volatile, Atomic_Components, and Volatile_Components is as follows:
+
+!corrigendum C.6(3)
+
+@ddel
+@xindent<@b<pragma> Atomic(@fa<local_name>);>
+
+!corrigendum C.6(4)
+
+@ddel
+@xindent<@b<pragma> Volatile(@fa<local_name>);>
+
+!corrigendum C.6(5)
+
+@ddel
+@xindent<@b<pragma> Atomic_Components(@i<array_>@fa<local_name>);>
+!corrigendum C.6(6)
+
+@ddel
+@xindent<@b<pragma> Volatile_Components(@i<array_>@fa<local_name>);>
+
+!comment %% C.6(7/2) and C.6(8) need changes here.
+
+!corrigendum C.6(9)
+
+@ddel
+The @fa<local_name> in an Atomic or Volatile pragma shall resolve
+to denote either an @fa<object_declaration>, a non-inherited @fa<component_declaration>,
+or a @fa<full_type_declaration>. The @i<array_>@fa<local_name> in an
+Atomic_Components or Volatile_Components pragma shall resolve to denote
+the declaration of an array type or an array object of an anonymous type.
+
+!corrigendum C.6(10)
+
+@drepl
+It is illegal to apply either an Atomic or Atomic_Components pragma to an object or type if
+the implementation cannot support the indivisible reads and updates required by the pragma
+(see below).
+@dby
+If aspect Independent_Components is specified for a
+@fa<full_type_declaration>, the declaration shall be that of an array or record type.
+
+It is illegal to specify the aspect Atomic or Atomic_Components to have the value True
+for an object or type if the implementation cannot support the indivisible reads and writes
+required by the aspect (see below).
+
+!corrigendum C.6(13)
+
+@drepl
+If a pragma Volatile, Volatile_Components, Atomic, or Atomic_Components applies to a stand-alone
+constant object, then a pragma Import shall also apply to it.
+@dby
+If an aspect Volatile, Volative_components, Atomic or Atomic_Components is
+directly specified to have the value True for a stand-alone constant object,
+then the aspect Import shall also be specified as True for it.
+
+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_Components is True,
+in a way that prevents the implementation from providing the
+independent addressability required by the aspect.
+
+!corrigendum C.6(14)
+
+@ddel
+These pragmas are representation pragmas (see 13.1).
+
!comment %% C.6(21) needs changes here.
@@ -2812,6 +3616,21 @@
!comment %% D.1(14), D.1(16), D.1(17), D.1(18), and D.1(19) need changes here.
+!corrigendum D.2.4(11/2)
+
+@drepl
+Since implementations are allowed to round all ceiling priorities in subrange System.Priority to
+System.Priority'Last (see D.3), an implementation may allow a task to execute within a protected object
+without raising its active priority provided the associated protected unit does not contain
+pragma Interrupt_Priority, Interrupt_Handler, or Attach_Handler.
+@dby
+Since implementations are allowed to round all ceiling priorities in subrange System.Priority to
+System.Priority'Last (see D.3), an implementation may allow a task to execute within a protected object
+without raising its active priority provided the associated protected unit does not contain
+any subprograms with Interrupt_Handler or Attach_Handler specified nor does the unit have aspect
+Interrupt_Priority specified.
+
+
!comment %% D.2.6(2/2), D.2.6(3/2), D.2.6(4/2), D.2.6(5/2), D.2.6(6/2), and D.2.6(9/2) need changes here.
!corrigendum D.2.6(12/2)
@@ -2900,6 +3719,20 @@
Attach_Handler specified, then the initial priority of the corresponding
protected object is System.Priority'Last.>
+!corrigendum D.5.2(6/2)
+
+@drepl
+If the locking policy Ceiling_Locking is in effect, then for a protected object @i<P> with either
+an Attach_Handler or Interrupt_Handler pragma applying to one of its procedures, a check is
+made that the value to be assigned to P'Priority is in the range System.Interrupt_Priority.
+If the check fails, Program_Error is raised.
+@dby
+If the locking policy Ceiling_Locking is in effect, then for a protected object @i<P> with either
+an Attach_Handler or Interrupt_Handler aspect specified for one of its procedures, a check is
+made that the value to be assigned to P'Priority is in the range System.Interrupt_Priority.
+If the check fails, Program_Error is raised.
+
+
!corrigendum D.13(5/2)
@drepl
@@ -3023,6 +3856,64 @@
of the procedure are all of mode @b<in>.
+!corrigendum F(7)
+
+@drepl
+If COBOL (respectively, C) is widely supported in the target environment, implementations supporting
+the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
+Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
+C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
+written in that language.
+@dby
+If COBOL (respectively, C) is widely supported in the target environment, implementations supporting
+the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
+Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
+C) in the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
+written in that language.
+
+
+!corrigendum F.2(6)
+
+@drepl
+@xcode< @b<generic>
+ @b<type> Dividend_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Divisor_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Quotient_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Remainder_Type @b<is delta> <@> @b<digits> <@>;
+ @b<procedure> Divide (Dividend : @b<in> Dividend_Type;
+ Divisor : @b<in> Divisor_Type;
+ Quotient : @b<out> Quotient_Type;
+ Remainder : @b<out> Remainder_Type);
+ @b<pragma> Convention(Intrinsic, Divide);>
+@dby
+@xcode< @b<generic>
+ @b<type> Dividend_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Divisor_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Quotient_Type @b<is delta> <@> @b<digits> <@>;
+ @b<type> Remainder_Type @b<is delta> <@> @b<digits> <@>;
+ @b<procedure> Divide (Dividend : @b<in> Dividend_Type;
+ Divisor : @b<in> Divisor_Type;
+ Quotient : @b<out> Quotient_Type;
+ Remainder : @b<out> Remainder_Type)
+ @b<with> Convention => Intrinsic;>
+
+
+!corrigendum G(7)
+
+@drepl
+If Fortran (respectively, C) is widely supported in the target environment, implementations supporting
+the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
+Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
+C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
+written in that language.
+@dby
+If Fortran (respectively, C) is widely supported in the target environment, implementations supporting
+the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
+Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
+C) in the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
+written in that language.
+
+
!corrigendum J.15(0)
@dinsc
@@ -3158,7 +4049,14 @@
The @i<convention_>@fa<identifier> of an interfacing pragma shall be the name of a convention (see B.1).
-A @fa<pragma> Import shall be the completion of a declaration.
+A @fa<pragma> Import shall be the completion of a declaration. Notwithstanding any rule to the
+contrary, a @fa<pragma> Import may serve as the completion of any kind of (explicit) declaration
+if supported by an implementation for that kind of declaration. If a completion is a @fa<pragma>
+Import, then it shall appear in the same @fa<declarative_part>, @fa<package_specification>,
+@fa<task_definition>, or @fa<protected_definition> as the declaration. For a library unit,
+it shall appear in the same @fa<compilation>, before any subsequent @fa<compilation_unit>s other
+than @fa<pragma>s. If the @fa<local_name>
+denotes more than one entity, then the @fa<pragma> Import is the completion of all of them.
The @i<external_name_string_>@fa<expression> and @i<link_name_string_>@fa<expression> of a
@fa<pragma> Import or Export shall be static.
@@ -3421,8 +4319,8 @@
The @fa<local_name> of a pragma Asynchronous shall denote a declaration that may have
aspect Asynchronous specified.
-
+!comment Revisions to K and the addition of K.1 and K.2 need to be reflected here.
!ACATS test
@@ -5692,6 +6590,573 @@
****************************************************************
+From: Bob Duff
+Sent: Tuesday, March 15, 2011 12:39 PM
+
+> In the minutes, you asked me to "send a complete list of aspects". I
+> presume this was a tactic to avoid doing the work on the Annex for as
+> long as possible. :-)
+
+;-)
+
+Actually, it was a tactic to avoid doing the hard work of tracking down all the aspect names.
+
+>...Sorry, but that tactic is now expired.
+>
+> Attached find a listing of the 65 specifiable aspects that I was able
+> to find. There might be some that I forgot about - feel free to tell
+> me if I missed something obvious.
+
+OK, thanks. Here's the wording you requested. It's intentionally very informal.
+Anybody who nitpicks it in a language-lawyerly way will be summarily shot. For
+once in our lives, we can place understandability over correctness!
+
+I left out "coding" and "record layout", because these are neither specifiable via
+an aspect clause, nor queryable. Programmers have no reason to care about these;
+they exist only to feed into the rule about not specifying the same thing twice.
+
+You listed Write'Class and friends. I think you mean Class'Write.
+Anyway, I left these 4 out. I figure, if anybody wants to look them up, they'll look
+up 'Write, and be sent to the right section.
+
+These are all formatted uniformly, so you can easily massage them with editor macros if
+you like. Separated by blank lines. First line is the section number where you should
+insert the macro call. Second line is the first three args. Third and subsequent lines
+are the wording.
+
+Let me know if you want me to do any such massaging -- I'm pretty good with Emacs macros.
+Just tell me how you want them formatted.
+
+One aspect (Implemented) has no section number. Didn't we rename this one, by the way?
+
+I included the explanatory text from your email after the section numbers.
+
+I don't know what "chgaspectdesc" means, but that's the macro name you told me to use.
+
+13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Pack],
+ Text=[Minimize storage when laying out records and arrays.]}
+
+13.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Address],
+ Text=[Machine address of an object.]}
+
+13.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Alignment],
+ Text=[Alignment of an object or type.]}
+
+13.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Size],
+ Text=[Size in bits of an object or type.]}
+
+13.3: -- Note this is an attribute and pragma combined; it will be different when rewritten.
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Storage_Size],
+ Text=[Amount of storage reserved for a task, or for objects allocated for a
+ given access type.]}
+
+13.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Component_Size],
+ Text=[Size in bits of an array object or type.]}
+
+13.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[External_Tag],
+ Text=[Unique identifier for a tagged type in streams.]}
+
+13.3.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Pre],
+ Text=[Precondition; a condition that must hold true before a call.]}
+
+13.3.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Pre'Class],
+ Text=[Precondition inherited on type derivation.]}
+
+13.3.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Post],
+ Text=[Postcondition; a condition that must hold true after a call.]
+
+13.3.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Post'Class],
+ Text=[Postcondition inherited on type derivation.]}
+
+13.3.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Type_Invariant],
+ Text=[A condition that must hold true for all objects of a type.]}
+
+13.3.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Type_Invariant'Class],
+ Text=[A condition that must hold true for all objects in a class of types.]}
+
+13.5.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Bit_Order],
+ Text=[Order of bit numbering in a record_representation_clause.]}
+
+13.11:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Storage_Pool],
+ Text=[Pool of memory from which "new" will allocate for a given access
+ type.]}
+
+13.11.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Controlled],
+ Text=[Garbage collection is disabled for a given access type.]}
+
+13.13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Stream_Size],
+ Text=[Size in bits used to represent elementary objects in a stream.]}
+
+13.13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Write],
+ Text=[Procedure to write a value to a stream for a given type.]}
+
+13.13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Read],
+ Text=[Procedure to read a value from a stream for a given type.]}
+
+13.13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Input],
+ Text=[Function to read a value from a stream for a given type, including
+ any bounds and discriminants.]}
+
+13.13.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Output],
+ Text=[Procedure to write a value to a stream for a given type, including any
+ bounds and discriminants.]}
+
+B.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Convention],
+ Text=[Calling convention or other convention used for interfacing to other
+ languages.]}
+
+B.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Import],
+ Text=[Entity is imported from another language.]}
+
+B.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Export],
+ Text=[Entity is exported to another language.]}
+
+B.1: - see wording in AI05-0229-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[External_Name],
+ Text=[Name used to identify an imported or exported entity.]}
+
+B.1: - see wording in AI05-0229-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Link_Name],
+ Text=[Linker symbol used to identify an imported or exported entity.]}
+
+B.3.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Unchecked_Union],
+ Text=[Type is used to interface to a C union type.]}
+
+F.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Machine_Radix],
+ Text=[Radix (2 or 10) used to represent a decimal fixed point type.]}
+
+C.5:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Discard_Names],
+ Text=[Avoid storing enumeration literal names, tagged type names, and
+ exception names at run time.]}
+
+E.4.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Asynchronous],
+ Text=[Inter-partition calls are asynchronous; the callee continues without
+ waiting for the call to return.]}
+
+10.2.1: - AI05-0243
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Pure],
+ Text=[Side effects are avoided in the subprograms of a given package.]}
+
+10.2.1: - AI05-0243-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Preelaborate],
+ Text=[Code execution during elaboration is avoided for a given package.]}
+
+E.2.3: - AI05-0243-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Remote_Call_Interface],
+ Text=[Subprograms in a given package are used in remote procedure calls.]}
+
+E.2.2: - AI05-0243-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Remote_Types],
+ Text=[Types in a given package are used in remote procedure calls.]}
+
+E.2.1: - AI05-0243-1
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Shared_Passive],
+ Text=[A given package is used to represent shared memory in a distributed
+ system.]}
+
+E.2.3:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[All_Calls_Remote],
+ Text=[All remote procedure calls should use the Partition Communication
+ Subsystem, even if they are local.]}
+
+10.2.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Elaborate_Body],
+ Text=[A given package must have a body, and that body is elaborated
+ immediately after the declaration.]}
+
+3.5.10:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Small],
+ Text=[Scale factor for a fixed point type.]}
+
+6.3.2:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Inline],
+ Text=[Inline calls are requested for a subprogram.]}
+
+10.2.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Preelaborable_Initialization],
+ Text=[Objects of a given type can be used in preelaborated packages.]}
+
+C.3.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Interrupt_Handler],
+ Text=[Protected procedure may be attached to interrupts.]}
+
+C.3.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Attach_Handler],
+ Text=[Protected procedure is attached to an interrupt.]}
+
+D.2.6:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Relative_Deadline],
+ Text=[Parameter used in Earliest Deadline First Dispatching.]}
+
+D.16:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[CPU],
+ Text=[Processor on which a given task should run.]}
+
+D.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Interrupt_Priority],
+ Text=[Priority of a task object or type, or ceiling priority of a protected
+ object or type; the priority is in the interrupt range.]}
+
+D.1:
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Priority],
+ Text=[Priority of a task object or type, or ceiling priority of a protected
+ object or type; the priority is not in the interrupt range.]}
+
+AI05-0215-1: - Ed has not updated this to date @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Implemented],
+ Text=[Implementation of a primitive operation of a synchronous interface --
+ as an entry or subprogram.]}
+
+3.2.4: - not in draft yet - see AI05-0153-3 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Static_Predicate],
+ Text=[Condition that must hold true for objects of a given subtype; the
+ subtype may be static.]}
+
+3.2.4: - not in draft yet - see AI05-0153-3 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Dynamic_Predicate],
+ Text=[Condition that must hold true for objects of a given subtype; the
+ subtype is not static.]}
+
+4.1.5: - not in draft yet - see AI05-0139-2 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Implicit_Dereference],
+ Text=[User-defined hook for implicit ".all".]}
+
+4.1.6: - not in draft yet - see AI05-0139-2 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Constant_Indexing],
+ Text=[User-defined hook for implementation of indexed_components.]}
+
+4.1.6: - not in draft yet - see AI05-0139-2 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Variable_Indexing],
+ Text=[User-defined hook for implementation of indexed_components.]}
+
+5.5.1: - not in draft yet - see AI05-0139-2 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Default_Iterator],
+ Text=[Default iterator to be used in "for" loops.]}
+
+5.5.1: - not in draft yet - see AI05-0139-2 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Iterator_Element],
+ Text=[Element type to be used for user-defined iterators.]}
+
+3.5: - not in draft yet - see AI05-0228-1 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Default_Value],
+ Text=[Default value for a scalar subtype.]}
+
+3.6: - not in draft yet - see AI05-0228-1 @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Default_Component_Value],
+ Text=[Default value for the components of an array-of-scalar subtype.]}
+
+[end of aspect wordings]
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 15, 2011 2:51 PM
+
+> OK, thanks. Here's the wording you requested. It's intentionally
+> very informal. Anybody who nitpicks it in a language-lawyerly way
+> will be summarily shot. For once in our lives, we can place
+> understandability over correctness!
+
+Here here!
+Incomprehensible correct stuff is never useful I lke the style of wording here.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 15, 2011 3:50 PM
+
+I found two mistakes, and one place I'd like to improve.
+
+> @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Component_Size],
+> Text=[Size in bits of an array object or type.]}
+
+Size in bits of components of an array object or type.
+
+> E.4.1:
+> @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Asynchronous],
+> Text=[Inter-partition calls are asynchronous; the callee continues without
+> waiting for the call to return.]}
+
+Remote procedure calls are asynchronous; the caller continues without
+ waiting for the call to return.
+
+calleR!
+
+> 6.3.2:
+> @chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Inline],
+> Text=[Inline calls are requested for a subprogram.]}
+
+For efficiency, inline calls are requested for a subprogram.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 15, 2011 5:53 PM
+
+> I left out "coding" and "record layout", because these are
+> neither specifiable via an aspect clause, nor queryable.
+> Programmers have no reason to care about these; they exist
+> only to feed into the rule about not specifying the same thing twice.
+
+We discussed this explicitly in St. Pete Beach, and came to the opposite
+conclusion:
+
+"Do we want aspects in the aspect annex that can't be specified with
+aspect_specification? For instance, enumeration rep clause. Yes, but we'll
+need to add wording to say that you use an enumeration rep clause rather
+than an aspect_specification."
+
+I personally don't care much either way about this issue, but when a
+question is asked and decided at an ARG meeting, generally there needs to be
+something not considered at the meeting in order to ignore the answer. I
+don't see it in your above explanation...
+
+> You listed Write'Class and friends. I think you mean Class'Write.
+> Anyway, I left these 4 out. I figure, if anybody wants to
+> look them up, they'll look up 'Write, and be sent to the
+> right section.
+
+Since there is no declaration for T'Class, in order to specify the attribute
+using an aspect we would need some other method. Given that we already have
+Pre'Class, it would make sense to also have Write'Class. But I admit that we
+would need wording to support this; in the absence of that wording, you can
+only specify these via attribute definition clauses.
+
+This sounds like a candidate for an early Ada 2012 Binding Interpretation.
+
+> These are all formatted uniformly, so you can easily massage
+> them with editor macros if you like. Separated by blank
+> lines. First line is the section number where you should
+> insert the macro call. Second line is the first three args.
+> Third and subsequent lines are the wording.
+>
+> Let me know if you want me to do any such massaging -- I'm
+> pretty good with Emacs macros. Just tell me how you want
+> them formatted.
+
+Doesn't look necessary. I'll probably spend a lot longer implementing the
+commands and the annex output than putting these into the draft. Most of the
+work will be finding the right place to drop these in.
+
+> One aspect (Implemented) has no section number. Didn't we
+> rename this one, by the way?
+
+See the messages from Ed later today.
+
+> I included the explanatory text from your email after the
+> section numbers.
+>
+> I don't know what "chgaspectdesc" means, but that's the macro
+> name you told me to use.
+
+"chg" - Change; this abbreviation was inherited from the Scribe version.
+"aspect" - Aspect; I hope this goes without saying.
+"desc" - Description.
+
+The "Chg" part is needed because these are newly added to the standard; we
+don't want them showing up in previous editions. (Not that there is a lot of
+likelyhood of generating old editions.) The "Version" is the source of the
+"/3" in the paragraph numbers that we all know and love; the "Kind"
+specifies the type of paragraph number: "Added" means it is new to this
+version, and "Normal" means it is not an inserted paragraph number. "Aspect"
+and "Text" are obvious.
+
+This is very similar to the way the Implementation Defined text is handled
+in the standard. The command used in the Ada 95 Scribe was "ImplDef" (which
+just took text). There is also @ImplDefList, which creates the body of the
+annex for all of the ImplDefs seen to date. New ImplDefs use "ChgImplDef",
+which added the change fields noted before. This seemed to be the closest
+analog.
+
+Far more information than you wanted, I hope. ;-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 15, 2011 6:55 PM
+
+> We discussed this explicitly in St. Pete Beach, and came to the
+> opposite
+> conclusion:
+>
+> "Do we want aspects in the aspect annex that can't be specified with
+> aspect_specification? For instance, enumeration rep clause. Yes, but
+> we'll need to add wording to say that you use an enumeration rep
+> clause rather than an aspect_specification."
+
+Oh, sorry, I don't remember that, and neglected to consult the minutes.
+Sounds like a "sure, what the heck, why not have Bob do some useless work". ;-)
+
+As you know, I think this Aspect Annex is close to useless, so I guess you won't
+trust my judgement that these two particular items ("coding" and "record layout")
+are utterly and totally and unutterably 100% useless.
+
+If we really must have such useless junk, then I suggest:
+
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[coding],
+ Text=[Internal representation of enumeration literals. Specified by an
+ enumeration_representation_clause, not by an aspect_specification.]}
+
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[record layout],
+ Text=[Layout of record components. Specified by a
+ record_representation_clause, not by an aspect_specification.]}
+
+> Since there is no declaration for T'Class, in order to specify the
+> attribute using an aspect we would need some other method. Given that
+> we already have Pre'Class, it would make sense to also have
+> Write'Class. But I admit that we would need wording to support this;
+> in the absence of that wording, you can only specify these via attribute
+> definition clauses.
+
+I see. In any case, they don't need to be in the annex.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 15, 2011 6:09 PM
+
+>> I left out "coding" and "record layout", because these are neither
+>> specifiable via an aspect clause, nor queryable.
+>> Programmers have no reason to care about these; they exist only to
+>> feed into the rule about not specifying the same thing twice.
+>
+> We discussed this explicitly in St. Pete Beach, and came to the
+> opposite
+> conclusion:
+>
+> "Do we want aspects in the aspect annex that can't be specified with
+> aspect_specification? For instance, enumeration rep clause. Yes, but
+> we'll need to add wording to say that you use an enumeration rep
+> clause rather than an aspect_specification."
+
+Why can't we have
+
+ type A is (B, C, D) with
+ Enum_Rep => (B => 1, C => 10, D => 20);
+
+Looks fine to me, I think we should allow anything that has the syntactic
+form of an expression, just as we do for pragmas.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 15, 2011 6:21 PM
+
+I suppose we could; I suspect that we didn't simply because it seemed to be
+of insufficient value. Gotta draw the line somewhere.
+
+Note that we did consider using aspect_specifications (probably on each
+component) instead of a record rep clause, and eventually decided that
+wasn't worth the effort. So in any case, you will still have some of the
+special forms around.
+
+I'm sure a proposal for Ada 2020 would be accepted for both of these...
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 15, 2011 6:43 PM
+
+I was discussing impl defined aspects with Bob just now, (a particular aspect
+we wanted to add to GNAT, not one we would propose for standardization at least
+not now), and we suggest that there be a general permission to have the syntax
+of impl-defined aspects be impl-defined. We don't see any harm in this, after
+all an impl defined aspect that is not recognized by an implementation is plain
+illegal, so what does it matter what form it has.
+
+Then GNAT could, if it likes add Enum_Rep and Record_Rep aspects, and then if
+they look useful and done right, Ada 2020 could adopt them later.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 15, 2011 6:45 PM
+
+> Why can't we have
+>
+> type A is (B, C, D) with
+> Enum_Rep => (B => 1, C => 10, D => 20);
+>
+> Looks fine to me, I think we should allow anything that has the
+> syntactic form of an expression, just as we do for pragmas.
+
+If you add that to the RM, next thing you know, ARG will move the
+enumeration_representation_clause syntax into the Obsolescent Annex!
+
+I think the above is probably valid as an impl-def aspect.
+But I think it's a waste of energy to implement it.
+And the other one is record reps -- I don't want to think about how to turn
+those into aspect clauses.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 15, 2011 7:04 PM
+
+> I think the above is probably valid as an impl-def aspect.
+> But I think it's a waste of energy to implement it.
+> And the other one is record reps -- I don't want to think about how to
+> turn those into aspect clauses.
+
+Well the easiest thing is to just allow exactly the same syntax, instead of
+
+ type R is record ...
+ for R use bla
+
+ type R is record ... with
+ Record_Representation => bla
+
+with exactly the same syntax for bla in both cases. I am not suggesting this
+to add to the RM right now, but it seems very straightforward to implement this.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, March 15, 2011 8:51 PM
+
+> > OK, thanks. Here's the wording you requested. It's intentionally
+> > very informal. Anybody who nitpicks it in a language-lawyerly way
+> > will be summarily shot. For once in our lives, we can place
+> > understandability over correctness!
+>
+> Here here!
+
+Thank you, but I think you mean:
+
+ Hear, hear!
+
+(I'm responding to a person who insists on the original meaning of "moot".)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, March 16, 2011 7:16 AM
+
+> Thank you, but I think you mean:
+>
+> Hear, hear!
+
+Indeed! I am always amazed at such typos writing quick email :-)
+
+****************************************************************
+
From: John Barnes
Sent: Thursday, April 7, 2011 5:48 AM
@@ -5820,8 +7285,8 @@
> A representation pragma or library unit pragma that has a single
> argument that is a local_name may be specified by an
-> aspect_specification, with the entity being the local_name. The aspect_definition is expected to be of type Boolean.
-> The expression shall be static.
+> aspect_specification, with the entity being the local_name. The aspect_definition
+> is expected to be of type Boolean. The expression shall be static.
surely it is not a pragma that is specified. (and stacking the "that"s 3-deep is
not nice). Suggested Rewrite:
@@ -6119,7 +7584,10 @@
From: Randy Brukardt
Sent: Friday, May 6, 2011 12:47 AM
-Tucker has suggested that we consider removing pragma Controlled from the core (and as a side-effect, not defining it as an aspect). He asks the question "Do *any* Ada compilers support the "Controlled" pragma/aspect?". I don't know of any.
+Tucker has suggested that we consider removing pragma Controlled from the core
+(and as a side-effect, not defining it as an aspect). He asks the question
+"Do *any* Ada compilers support the "Controlled" pragma/aspect?". I don't know of
+any.
As a pragma, we wouldn't even need to move this to Annex J; it could simply
disappear.
@@ -6851,5 +8319,125 @@
I recommend you leave it basically as is, but perhaps add some general comment like
"(note that corresponding statements could be made about aspects and
aspect_specifications)".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, August 10, 2011 8:44 PM
+
+While looking at AARM notes changing pragmas to aspects, I was pointed to the
+following paragraph:
+
+1.1.3(17) says:
+
+An implementation conforming to this International Standard may provide additional
+attributes, library units, and pragmas. However, it shall not provide any attribute,
+library unit, or pragma having the same name as an attribute, library unit, or pragma
+(respectively) specified in a Specialized Needs Annex unless the provided construct
+is either as specified in the Specialized Needs Annex or is more limited in capability
+than that required by the Annex. A program that attempts to use an unsupported capability
+of an Annex shall either be identified by the implementation before run time or shall
+raise an exception at run time.
+
+I think it goes without saying that we intend this to apply to specifiable aspects that
+are defined in Annexes as well as the constructs named. Other than that we in fact
+have to say it. ;-) Otherwise, it would seem that we intentionally left out aspects,
+allowing people to redefine things like the Priority and Atomic aspects.
+
+So I propose to add "aspect, " in front of each use of attribute in this text (with
+the proper plurals where needed).
+
+This seemed significant enough to bring it up to the group, but as I don't expect
+opposition, I'll do this as part of AI05-0229-1 unless there is a strong objection.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, August 10, 2011 10:12 PM
+
+Works for me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 11, 2011 12:14 AM
+
+.11.1 prattles on and on with exceptions for pragmas that are completions.
+
+With the various aspect changes, there are no longer any such
+(language-defined) pragmas. Pragma Import sets aspect Import; a completion
+is not allowed for any entity for which aspect Import is True -- this is a
+"Notwithstanding" rule; along with that, I modified 3.11.1(6):
+
+An implicit declaration shall not have a completion. For any explicit
+declaration that is specified
+to @i<require completion>, there shall be a corresponding explicit
+completion, unless the declared
+entity is imported (see B.1).
+
+[I was going to add a To Be Honest note instead, but decided that was silly
+when the correct wording was easy.]
+
+Anyway, I was trying to decide whether the entire idea of pragmas being
+completions should be scrubbed (I think it only appears here now). For now,
+I decided on a cop-out, and added the following AARM note at the top of the
+section:
+
+AARM Discussion: In Ada 2012, there are no language-defined pragmas that act
+as completions. Pragma Import (which is obsolescent) has the effect of
+setting aspect Import to True; such an aspect makes giving a completion
+illegal. We considered removing the wording which allows pragmas as
+completions, but decided to leave it for the benefit for
+implementation-defined pragmas which may want to act as a completion.
+
+Actually removing the wording isn't that hard (there is only some in
+paragraphs 1, 4, and 5 -- para 9, which is a note, had to be rewritten
+anyway). I've changed literally hundreds of paragraphs for the aspect
+changes, three more would hardly be noticiable. So the work isn't a reason
+to leave the pragmas in the wording.
+
+Should the wording be removed (along with the new note)? An
+implementation-defined pragma can do whatever it wants, and surely we don't
+need wording in the Standard just to support those as completions.
+
+P.S. I'm almost done scrubbing the standard for old "pragma Import" AARM
+notes. There sure are a lot. Once that's done, I'll have finished all of the
+"important" work on the Standard (lots of other things, like Gary's commas).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, August 11, 2011 1:01 AM
+
+...
+> Should the wording be removed (along with the new note)? An
+> implementation-defined pragma can do whatever it wants, and surely we
+> don't need wording in the Standard just to support those as
+> completions.
+
+I may have answered my own question. I hadn't noticed (or remembered)
+2.8(18) when I wrote that; we're surely not dropping that advice [although I
+dropped the part about pragma Import, since it is a lie now] and it would be
+kinda weird to explicitly allow such pragmas but never say what they mean.
+
+So I think I already have this right.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, August 11, 2011 6:41 AM
+
+> I may have answered my own question. I hadn't noticed (or remembered)
+> 2.8(18) when I wrote that; we're surely not dropping that advice
+> [although I dropped the part about pragma Import, since it is a lie
+> now] and it would be kinda weird to explicitly allow such pragmas but
+> never say what they mean.
+>
+> So I think I already have this right.
+
+I agree. Let's not (again!) get into an argument about the kludgery in and
+near 2.8(18).
+
+If it ain't broke, don't fix it. Very broke.
****************************************************************
Questions? Ask the ACAA Technical Agent