CVS difference for ai05s/ai05-0229-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai05s/ai05-0229-1.txt

--- ai05s/ai05-0229-1.txt	2011/03/18 00:11:53	1.8
+++ ai05s/ai05-0229-1.txt	2011/03/26 07:49:22	1.9
@@ -1,4 +1,4 @@
-!standard 13.2(5)                                    11-03-17  AI05-0229-1/04
+!standard 13.2(5)                                    11-03-25  AI05-0229-1/05
 !standard 13.11.3(5)
 !standard B.3.3(4)
 !standard E.4.1(8)
@@ -74,7 +74,8 @@
 not the entire partition. 
 
 AARM Note: The pragmas have exactly the functionality of the corresponding aspect,
-and rejecting could be a significant portability problem for existing code.
+(unlike the typical obsolescent feature) and rejecting them could be a significant
+portability problem for existing code.
 
 
 Changes for individual pragmas:
@@ -217,42 +218,128 @@
 Controlled] has no effect. 
 
 
-** Unchanged - TBD **
-===pragma Unchecked_Union:
+===pragma Unchecked_Union: (the pragma is to be obsolescent)
 
-Modify B.3.3(4/2):
-Unchecked_Union is a representation pragma[, specifying the unchecked
-union aspect of representation].
+Change the title of clause B.3.3 to "Unchecked Union Types". 
 
-Add Unchecked_Union to the index under "representation pragma".
+Modify B.3.3(1/2):
 
-** Unchanged - TBD **
+[Redundant: {Specifying aspect Unchecked_Union to have value True defines}[A pragma Unchecked_Union
+specifies] an interface correspondence between a given discriminated type and some C union.
+The {aspect requires}[pragma specifies] that the associated type {is}[shall be] given a
+representation that leaves no space for its discriminant(s).] 
+
+Add after B.3.3(1/2):
+
+  For a discriminated record type having a variant_part, the following language-defined
+  representation aspect may be specified:
+     Unchecked_Union
+      The type of aspect Unchecked_Union is Boolean.
+      If directly specified, the aspect_definition shall be a static expression.
+      If not specified (including by inheritance), the aspect is False.
+
+
+Delete B.3.3(2-5/2) [Now in Annex J.]
+
+Modify B.3.3(6/2):
+
+A type {for}[to] which {aspect}[a pragma] Unchecked_Union {is True}[applies] is called an
+*unchecked union type*. A subtype of an unchecked union type is defined to be an *unchecked
+union subtype*. An object of an unchecked union type is defined to be an *unchecked union object*.
+
+Modify B.3.3(29/2):
+
+An implementation may require that {aspect Controlled is True}[pragma Controlled be specified]
+for the type of an access subcomponent of an unchecked union type.
+
+
 ===pragma Discard_Names:
 
-C.5(6): No changes needed for Discard_Names.
+[Editor's note: Can't get rid of this pragma; its use as a configuration pragma or to apply
+to all entities in a package specification cannot be modeled as an aspect.]
 
-** Unchanged - TBD **
+C.5: No changes needed for Discard_Names; the general wording for using representation
+pragmas as aspects applies here.
+
+Add an AARM Ramification after C.5(6): Representation pragmas are automatically aspects,
+so Discard_Names can be used as an aspect_mark in an aspect_specification instead of
+using the pragma on individual entities.
+
+[Editor's note: We could try to reword this to recommend using an aspect rather than
+the (On => local_name) form, but it doesn't seem worth the effort. The AARM note is just
+to mention the possibility. We could also make something similar into a user note.]
+
+
+** Unchanged - TBD ** -- Assigned to Ed.
 ===pragma Atomic, Atomic_Components, Independent,
 Independent_Components, Volatile, Volatile_Components:
 
 C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
 Independent_Components, Volatile, Volatile_Components.
 
-** Unchanged - TBD **
-===pragma Asynchronous:
+===pragma Asynchronous: (the pragma is to be obsolescent)
+
+Change the title of clause E.4.1 to "Asynchronous Remote Calls". 
+
+Modify E.4.1(1):
+
+[Redundant: This subclause introduces the {aspect}[pragma] Asynchronous which
+{which can be specified to allow}[allows] a remote subprogram call to return prior
+to completion of the execution of the corresponding remote subprogram body.] 
+
+Delete E.4.1(2-3). [Now in Annex J.]
+
+Add after E.4.1(3):
+
+  For a remote procedure, the following language-defined
+  representation aspect may be specified:
+     Asynchronous
+      The type of aspect Asynchronous is Boolean.
+      If directly specified, the aspect_definition shall be a static expression.
+      If not specified, the aspect is False.
+
+  For a remote access type, the following language-defined
+  representation aspect may be specified:
+     Asynchronous
+      The type of aspect Asynchronous is Boolean.
+      If directly specified, the aspect_definition shall be a static expression.
+      If not specified (including by inheritance), the aspect is False.
+
+Replace E.4.1(4-7) with:
+
+If aspect Asynchronous is specified for a remote procedure, the formal parameters
+of the procedure shall all be of mode *in*.
+
+If aspect Asynchronous is specified for a remote access type, the type shall be
+a remote access-to-class-wide type, or the type shall be a remote access-to-procedure
+type with the formal parameters of the designated profile of the type all of mode *in*.
+
+Delete E.4.1(8).
+
+Modify E.4.1(9):
 
-Modify E.4.1(8):
-A pragma Asynchronous is a representation pragma.[ When applied to a
-type, it specifies the type-related asynchronous aspect of the type.]
+A remote call is asynchronous if it is a call to a procedure, or a call through
+a value of an access-to-procedure type, to which {aspect}[a pragma] Asynchronous
+{is True}[applies]. In addition, if {aspect}[a pragma] Asynchronous
+{is True}[applies] to a remote access-to-class-wide type, then a dispatching call
+on a procedure with a controlling operand designated by a value of the type is
+asynchronous if the formal parameters of the procedure are all of mode in. 
 
+Edit AARM notes E.4(20.g-20.h) to replace "pragma Asychronous is applied" with
+"aspect Asychronous is specified". E.4(20.i) "pragma" becomes "aspect".
 
-Library unit pragmas: (Somewhat covered by the general wording)
 
-[Editor's note: We still need to recast these as aspects, and a particular
-kind of aspect in order to invoke the aspect-specific wording
-(particularly 13.1(9)). The general wording only provides the Boolean
-value and staticness rules.]
+Library unit pragmas:
 
+[Editor's note: We still need to mention that these are also aspects,
+even though the general wording for library unit pragmas provides the
+Boolean value and staticness rules. We don't add any rules that
+prevent giving both the pragma and the aspect, since it is OK to
+give the pragma more than once. Also note that for pragmas that
+are usually used with library units, we're keeping the pragmas as
+the primary way to specify these things (they're not moving to
+Annex J).]
+
 ===pragma Pure:
 
 See AI05-0243-1.
@@ -273,14 +360,15 @@
 
 See AI05-0243-1.
 
-** Unchanged - TBD **
 ===pragma All_Calls_Remote
 
+[Editor's note: As a pragma that applies to a package, we're not going to make it
+obsolescent.]
+
 Replace E.2.3(16):
 
 A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the
-library unit to which it applies to the value True; the aspect may also be set
-by the aspect_specification of the library_item. If the All_Calls_Remote aspect
+library unit to which it applies to the value True. If the All_Calls_Remote aspect
 of a library unit is True, the library unit shall be a remote call
 interface.
 
@@ -289,9 +377,13 @@
 If [a pragma]{aspect} All_Calls_Remote [applies to]{is True for} a
 given RCI library unit, ...
 
-** Unchanged - TBD **
+
 ===pragma Elaborate_Body
 
+[Editor's note: As a pragma that applies to a package, we're not going to make it
+obsolescent. But note that we still have to write the semantics in terms of the
+aspect so that whether the pragma or aspect is used is irrelevant.]
+
 Replace 10.2.1(25):
 
 If the aspect Elaborate_Body is True for a declaration, then the
@@ -300,11 +392,11 @@
 Delete the last sentence of 10.2.1(26), then add a new paragraph following:
 
 A pragma Elaborate_Body sets the Elaborate_Body representation aspect of the
-library unit to which it applies to the value True; the aspect may also be set
-by the aspect_specification of the library_item. If the Elaborate_Body aspect
+library unit to which it applies to the value True. If the Elaborate_Body aspect
 of a library unit is True, the body of the library unit is elaborated
 immediately after its declaration.
 
+
 ===pragma Inline (the pragma is to be obsolescent)
 
 Delete 6.3.2(2-4). [Now in Annex J.]
@@ -338,7 +430,7 @@
 
 Other pragmas:
 
-** Unchanged - TBD **
+** Unchanged - TBD ** - Assigned to Steve
 ===pragma Preelaborable_Initialization
 
 Replace 10.2.1(11.6/2):
@@ -543,6 +635,8 @@
 immediately enclosing task_definition to the value of the expression of the
 pragma.
 
+
+** Unchanged - TBD **
 ===pragma Relative_Deadline
 
 Delete the last sentence of D.2.6(6/2) [it follows from the aspect rules.]
@@ -579,6 +673,7 @@
 deadline of a task is the value of Default_Deadline. [The environment task is
 also given an initial deadline by this rule.]
 
+** Unchanged - TBD **
 ===pragma CPU
 
 [Editor's note: I've left the definition of the pragma, mainly because using the
@@ -627,6 +722,7 @@
 main subprogram it is implementation defined on which processor the environment
 task executes.
 
+** Unchanged - TBD **
 ===pragma Interrupt_Priority, Priority
 
 Add after D.1(5):
@@ -730,7 +826,7 @@
 
 See AI05-0215-1.
 
-** Unchanged - TBD **
+** Unchanged - TBD ** -- Assigned to Tucker.
 ===pragmas Convention, Export, Import:
 
 Modify B.1(28) as follows:
@@ -755,11 +851,15 @@
 
 See AI05-0167-1.
 
+** TBD -- born obsolescent pragma.
 
+
 Add a new clause to Annex J:
 
 [Note: The subclauses will be rearranged in alphabetical order - at the last
-moment.]
+moment. Also, these pragmas will be indexed in the pragma Annex L; we don't
+want people to freak out when they can't find pragma Pack or pragma Inline
+there (and it will lead them to the right place).]
 
 J.15 Aspect-related pragmas
 
@@ -879,6 +979,45 @@
 
 A pragma Controlled is a representation pragma that specifies the Controlled aspect (see 13.11.3)
 for the type denoted by *first_subtype_*local_name has the value True.
+
+
+J.15.5 Pragma Unchecked_Union
+
+Syntax
+
+The form of a pragma Unchecked_Union is as follows:
+
+  pragma Unchecked_Union (first_subtype_local_name);
+
+Legality Rules
+
+The first_subtype_local_name of a pragma Unchecked_Union shall denote an unconstrained discriminated
+record subtype having a variant_part.
+
+Static Semantics
+
+A pragma Unchecked_Union is a representation pragma that specifies the Unchecked_Union aspect
+(see B.3.3) for the type denoted by *first_subtype_*local_name has the value True.
+
+
+J.15.6  Pragma Asynchronous
+
+Syntax
+
+The form of a pragma Asynchronous is as follows: 
+
+  pragma Asynchronous(local_name); 
+
+Static Semantics
+
+For an implementation that supports Annex E, a pragma Asynchronous is a representation pragma
+that specifies the Asynchronous aspect (see E.4.1) for the procedure or type denoted by local_name
+has the value True.
+
+Legality Rules
+
+The local_name of a pragma Asynchronous shall denote a declaration that is may have aspect
+Asynchronous specified.
 
 
 *** Additional obsolescent pragmas here ***

Questions? Ask the ACAA Technical Agent