CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/01/27 06:06:17 1.5
+++ ai05s/ai05-0229-1.txt 2011/02/16 03:48:11 1.6
@@ -1,7 +1,8 @@
-!standard 13.2(5) 10-10-25 AI05-0229-1/01
+!standard 13.2(5) 11-02-15 AI05-0229-1/02
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
+!standard K.1(0)
!class Amendment 10-10-25
!status work item 10-10-25
!status received 10-10-25
@@ -15,99 +16,799 @@
!problem
-The new aspect clauses (see AI05-0183-1) provide convinient syntax for
+The new aspect clauses (see AI05-0183-1) provide convenient syntax for
specifying aspect values. We ought to be able to use that syntax to specify
existing aspects as well as new ones.
!proposal
+Rewrite as needed to make many pragmas into aspects.
-
!wording
-[Author's note: I've no idea where the following wording belongs.]
+Replace the penultimate paragraph of the Static Semantics
+in AI05-0183-1:
-The following aspects may be used as an aspect_mark:
- - Each specifiable attribute may be specified by an
- attribute_definition_clause, as explained in 13.3, or by an
- aspect_specification, with the same semantics.
+All specifiable operational and representation attributes may be
+specified with an aspect_specification instead of an
+attribute_definition_clause (see 13.3). The attribute_designator is
+used for the aspect_mark.
- - A representation 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_mark being the same as the pragma name. The
- aspect_definition is expected to be of type Boolean. The expression shall
- be static with value True.
+A representation pragma or program 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 and the aspect_mark being the same as the pragma name. The
+aspect_definition is expected to be of type Boolean. The expression shall be
+static with value True.
- - Additional aspects that are neither attributes nor pragmas are defined
- throughout this International Standard.
+[Editor's note: The "=> True" part can be omitted by an existing rule
+- see AI05-0183-1. An AARM Note seems like overkill as that rule will
+be only a couple of paragraphs away from this one.]
-AARM Discussion:
+In addition, other operational and
+representation aspects not associated with specifiable attributes may
+be specified, as specified elsewhere in this International Standard.
- The following representation pragmas may also be specified using an
- aspect_specification:
+Changes for individual pragmas:
- Asynchronous E.4.1(8)
- Atomic C.6(14)
- Atomic_Components C.6(14)
- Controlled 13.11.3(5)
- Discard_Names C.5(6)
- Independent C.6(14)
- Independent_Components C.6(14)
- Pack 13.2(5)
- Volatile C.6(14)
- Volatile_Components C.6(14)
- Unchecked_Union
+Representation pragmas: (Covered by the general wording).
- The following representation pragmas cannot be specified using an
- aspect_specification, because the pragma arguments wouldn't make
- sense as an aspect_definition:
+===pragma Pack:
- CPU ???
- Convention B.1(28)
- Export B.1(28)
- Import B.1(28)
+Change "packing" to "Pack" in 13.3(55.e), 13.3(72), 13.3(72.a), 13.1(7.g),
+9.10(1/3), 9.10(1.c), 13.6(1).
-End AARM Discussion.
+[Note: We're only changing uses where "packing is specified" or the like.]
-(Seems like the above should be part of AI05-0183-1.
-I can understand why you might want the stuff below in a separate AI.)
+Modify 13.2(5):
-Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3).
+[A pragma Pack specifies the packing aspect of representation; ]
+{Pragma Pack is a representation pragmaRedundant[; it specifies the Pack aspect
+with the value True]. If the aspect Pack has the value True, }
+the type (or the extension part) is said to be packed. For a type extension, the
+parent part is packed as for the parent type, and [a pragma]{specifying} Pack
+causes packing only of the extension part.
-Remove all wording for representation pragmas that says this pragma specifies
-so-and-so aspect:
+Modify C.6(21):
-13.2(5):
-5 [A pragma Pack specifies the packing aspect of representation; ]
-{If Pack is specified, } the type (or the extension part) is said to be packed.
-For a type extension, the parent part is packed as for the parent type, and a
-pragma Pack causes packing only of the extension part.
+If [a pragma Pack applies to]{the Pack aspect has the value True for} a type any
+of ...
-13.11.3(5):
-5 A pragma Controlled is a representation pragma[ that specifies the
+
+===pragma No_Return
+
+6.5.1(2): No changes needed for No_Return.
+
+===pragma Controlled:
+
+Modify 13.11.3(5):
+A pragma Controlled is a representation pragma[ that specifies the
controlled aspect of representation].
-B.3.3(4/2):
-4/2 Unchecked_Union is a representation pragma[, specifying the unchecked
+===pragma Unchecked_Union:
+
+Modify B.3.3(4/2):
+Unchecked_Union is a representation pragma[, specifying the unchecked
union aspect of representation].
+Add Unchecked_Union to the index under "representation pragma".
+
+===pragma Discard_Names:
+
C.5(6): No changes needed for Discard_Names.
+===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.
-E.4.1(8):
-8 A pragma Asynchronous is a representation pragma.[ When applied to a
+===pragma Asynchronous:
+
+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.]
-Add Unchecked_Union to the index under "representation pragma".
+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.]
+
+===pragma Pure:
+
+See AI05-0243-1.
+
+===pragma Preelaborate:
+
+See AI05-0243-1.
+
+===pragma Remote_Call_Interface
+
+See AI05-0243-1.
+
+===pragma Remote_Types
+
+See AI05-0243-1.
+
+===pragma Shared_Passive
+
+See AI05-0243-1.
+
+===pragma All_Calls_Remote
+
+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 can also be set
+by the aspect_specification of the library_item. If the All_Calls_Remote aspect
+of a library unit has the value True, the library unit shall be a remote call
+interface.
+
+Modify E/2/3(19/1):
+
+If [a pragma]{aspect} All_Calls_Remote [applies to]{has the value True for} a
+given RCI library unit, ...
+
+===pragma Elaborate_Body
+
+Replace 10.2.1(25):
+
+If the aspect Elaborate_Body has the value True for a declaration, then the
+declaration requires a completion (body).
+
+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 can also be set
+by the aspect_specification of the library_item. If the Elaborate_Body aspect
+of a library unit has the value True, the body of the library unit is elaborated
+immediately after its declaration.
+
+Program 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.]
+
+===pragma Inline
+
+Modify 6.3.2(4):
+
+The pragma shall apply to{, or the Inline aspect shall be specified for,} one or
+more callable entities.
+
+Insert before 6.3.2(5):
+
+A pragma Inline sets the Inline representation aspect of the program unit
+to which it applies to the value True; the aspect can also be set
+by the aspect_specification of the library_item.
+
+Modify 6.3.2(5):
+
+If [a pragma Inline applies to]{aspect Inline has the value True for} a callable
+entity, this indicates that inline expansion is desired for all calls to that
+entity. If [a pragma Inline applies to]{aspect Inline has the value True for} a
+generic subprogram, this indicates that inline expansion is desired for all
+calls to all instances of that generic subprogram.
+
+Other pragmas:
+
+===pragma Preelaborable_Initialization
+
+Replace 10.2.1(11.6/2):
+
+A pragma Preelaborable_Initialization sets the Preelaborable_Initialization
+operational aspect of the type denoted by direct_name to the value True; the
+aspect can also be set by the aspect_specification of the declaration of a type.
+The pragma shall only appear in the visible part of a package or generic
+package. The aspect Preelaborable_Initialization shall only be specified for a
+composite type declared in the visible part of a package or generic package.
+
+[Note: This has to be an operational aspect, in order to be allowed to appear on
+a partial view.]
+
+Replace the middle three sentences of 10.2.1(11.7/3):
+
+If the aspect has the value True for a private type or a private extension, the
+full view of the type shall have preelaborable initialization. If the aspect has
+the value True for a protected type, the protected type shall not have entries,
+and each component of the protected type shall have preelaborable
+initialization. If the aspect has the value True for any other composite type,
+the type shall have preelaborable initialization.
+
+Replace 10.2.1(11.8/3):
+
+If the pragma appears in a generic_formal_part, then the direct_name shall
+denote a generic formal private type or a generic formal derived type declared
+in the same generic_formal_part as the pragma. In a generic_instantiation the
+actual type corresponding to a generic formal type with the
+Preelaborable_Initialization aspect having the value True shall have
+preelaborable initialization.
+
+AARM Ramification: This aspect can be specified on generic formal types that
+might be composite.
+
+[Editor's Note: Better redo the AARM note in AI05-0183-1 to mention this!]
+
+[Editor: It might have been better to recast the entire
+"preelaborable_initialization" (PI) property as an operational aspect of the
+type. That would require a lot more rewording, as types that "have" PI would
+instead have the PI aspect with a value of True; types that have PI specified
+would have to be completed with full types that also have PI with a value of
+True, and so on. That seems like it would involve a lot of opportunities for
+errors, so I went with the minimal change (even though it doesn't make much
+sense logically).]
+
+===pragma Interrupt_Handler
+
+Insert before C.3.1(7/3):
+
+Static Semantics
+
+The Attach_Handler and Interrupt_Handler representation aspects can be specified
+on a protected procedure; the aspect_mark is the same as the name of the aspect.
+When the Interrupt_Handler aspect is specified the aspect_definition is expected
+to be an expression of type Boolean. The expression shall be static with value
+True. When the Attach_Handler aspect_mark is specified, the aspect_definition is
+expected to the an expression of type Interrupts.Interrupt_Id.
+
+A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the
+protected procedure handler_name to have the value True. A pragma Attach_Handler
+specifies the AttacheHandler aspect for the protected procedure handler_name to
+have the value of the given expression Redundant[as evaluated at object creation
+time].
+
+Delete the last sentence of C.3.1(7/3) [it is being moved down].
+
+Add after C.3.1(7/3):
+
+If either the Attach_Hander or Interrupt_Handler aspect are specifed for a
+protected procedure, it shall have a parameterless profile, the corresponding
+protected_type_declaration or single_protected_declaration shall be a
+library-level declaration, and shall not be declared within a generic body.
+
+In addition to the places where Legality Rules normally apply (see 12.3), these
+rules also apply in the private part of an instance of a generic unit.
+
+Replace C.3.1(9):
+
+If a protected procedure has the aspect Interrupt_Handler with the value True,
+then the procedure can be attached dynamically, as a handler, to interrupts (see
+C.3.2). Redundant[Such procedures are allowed to be attached to multiple
+interrupts.]
+
+Replace C.3.1(10):
+
+The value of the Attach_Handler aspect specifies an interrupt. As part of the
+initialization of the associated object, if the Attach_Handler aspect is
+specified, the handler procedure is attached to the specified interrupt. A check
+is made that the corresponding interrupt is not reserved. Program_Error is
+raised if the check fails, and the existing treatment for the interrupt is not
+affected.
+
+Modify C.3.1(11/2):
+
+If the Ceiling_Locking policy (see D.3) is in effect, then upon the
+initialization of a protected object for which either {the}[an] Attach_Handler
+or Interrupt_Handler [pragma applies to]{aspect is specified for} one of its
+procedures, a check is made that the ceiling priority defined in the
+protected_definition is in the range of System.Interrupt_Priority. If the check
+fails, Program_Error is raised.
+
+Modify C.3.1(12/1):
+
+When a protected object is finalized, for any of its procedures that are
+attached to interrupts, the handler is detached. If the handler was attached by
+a procedure in the Interrupts package or if no user handler was previously
+attached to the interrupt, the default treatment is restored. If [an
+Attach_Handler pragma was used]{the Attach_Handler aspect was specified} and the
+most recently attached handler for the same interrupt is the same as the one
+that was attached at the time the protected object was initialized, the previous
+handler is restored.
+
+Modify C.3.1(14/1/1):
+
+If the handlers for a given interrupt attached via [pragma]{aspect}
+Attach_Handler are not attached and detached in a stack-like (LIFO) order,
+program execution is erroneous. In particular, when a protected object is
+finalized, the execution is erroneous if any of the procedures of the protected
+object are attached to interrupts via [pragma]{aspect} Attach_Handler and the
+most recently attached handler for the same interrupt is not the same as the one
+that was attached at the time the protected object was initialized.
+
+Modify C.3.1(17):
+
+When the [pragmas]{aspects} Attach_Handler or Interrupt_Handler [apply to]{are
+specified for} a protected procedure, the implementation is allowed to impose
+implementation-defined restrictions on the corresponding
+protected_type_declaration and protected_body.
+Modify C.3.1(19):
+
+Notwithstanding what this subclause says elsewhere, the Attach_Handler and
+Interrupt_Handler pragmas {and aspects} are allowed to be used for other,
+implementation defined, forms of interrupt handlers.
+
+Modify C.3.1(22):
+
+The Attach_Handler {aspect}[pragma] can provide static attachment of handlers to
+interrupts if the implementation supports preelaboration of protected objects.
+(See C.4.)
+
+[Also, make similar changes to the AARM notes at the end of the clause.]
+
+===pragma Storage_Size
+
+[Note: The existing attribute allows specification of Storage_Size for a task
+type *but* that attribute is obsolescent! Moreover, it would evaluate the
+expression too soon (when the type is frozen). I wrote specific wording to match
+the pragma. Not sure how to resolve the conflict with the obsolescent attribute,
+I used a TBH. Perhaps AI-183 needs to say something about not using "automatic"
+aspects if there is one with the same name explicitly defined??]
+
+Modify 13.3(60):
+
+...used by some implementations.) If [a pragma Storage_Size is given]{the aspect
+Storage_Size is specified for the type of the object}, the value of the
+Storage_Size attribute is at least the value [specified in the
+pragma]{determined by the aspect}.
+
+[Editor's note: This last sentence is redundant with the wording below. The
+original wording is wrong, since the value is not "specified in the pragma", it
+is determined when the pragma is elaborated.]
+
+Add after 13.3(61):
+
+Static Semantics
+
+The representation aspect Storage_Size may be specified for a
+task_type_declaration or a single_task_declaration. The value of the aspect is
+an expression.
+
+AARM To Be Honest: This definition conflicts with the "automatic" one for the
+obsolescent attribute Storage_Size. We intend for that "automatic" one to not be
+used for that attribute.
+
+[Add an AARM note in J.9 to mention this.]
+
+Name Resolution Rules
+
+When the aspect Storage_Size is specified, the aspect_definition is an
+expression which is expected to be of any integer type.
+
+Dynamic Semantics
+
+When a task object with a specified Storage_Size is elaborated, the expression
+associated with the aspect is evaluated; the Storage_Size attribute of the newly
+created task object is at least the value of the expression.
+
+At the point of task object creation, or upon task activation, Storage_Error is
+raised if there is insufficient free storage to accommodate the requested
+Storage_Size.
+
+
+Delete 13.3(66-67), replacing them by:
+
+Static Semantics
+
+The pragma Storage_Size sets the Storage_Size aspect of the type defined by the
+immediately enclosing task_definition to the value of the expression of the
+pragma.
+
+===pragma Relative_Deadline
+
+Delete the last sentence of D.2.6(6/2) [it follows from the aspect rules.]
+
+Add after D.2.6(9/2):
+
+The Relative_Deadline representation aspect can be specified on a
+task_type_declaration, a single_task_declaration, a subprogram_declaration. The
+value of the aspect is an expression.
+
+[Note: We have to use "subprogram_declaration" here, as aspects are not allowed
+in bodies. In the case of specifying this for the main subprogram, the pragma
+might be preferred to the aspect because a separate specification is not
+required.]
+
+When the aspect Relative_Deadline is specified, the aspect_definition is an
+expression which is expected to be of type Real_Time.Time_Span.
+
+The pragma Relative_Deadline sets the Relative_Deadline aspect of the enclosing
+task or subprogram to the relative_deadline_expression.
+
+Replace D.2.6(12/2):
+
+The Relative_Deadline aspect has no effect if it is specified for a subprogram
+other than the main subprogram.
+
+Modify D.2.6(13/2):
+
+The initial absolute deadline of a task {for which the}[containing pragma]
+Relative_Deadline {aspect is specified} is the value of Real_Time.Clock +
+[relative_deadline_]expression{ of the aspect}, where the call of
+Real_Time.Clock is made between task creation and the start of its activation.
+If there is no Relative_Deadline [pragma]{aspect} then the initial absolute
+deadline of a task is the value of Default_Deadline. [The environment task is
+also given an initial deadline by this rule.]
+
+===pragma CPU
+
+[Editor's note: I've left the definition of the pragma, mainly because using the
+aspect is annoying for the main subprogram. See Relative_Deadline for more
+discussion.]
+
+Replace D.16(9/3):
+
+[Note: The original wording here is ambiguous.]
+
+When the aspect CPU is specified, the aspect_definition is an expression which
+is expected to be of type System.Multiprocessors.CPU_Range. The expected type
+for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.
+
+Add after D.16(9/3):
+
+Static Semantics
+
+The CPU representation aspect can be specified on a task_type_declaration, a
+single_task_declaration, a subprogram_declaration. The value of the aspect is an
+expression.
+
+The pragma CPU sets the CPU aspect of the enclosing task or subprogram to the
+expression.
+
+Delete the second sentence of D.16(10/3). [This follows from the rules for
+aspects.]
+
+Add to the end of D.16(11/3): If the CPU aspect is specified for a subprogram,
+the expression shall be static.
+
+Modify D.16(12-4/3):
+
+The expression [of a CPU pragma that appears in a task_definition]{specifed for
+the CPU aspect of a task} is evaluated for each task object (see 9.1). The CPU
+value is then associated with the task object whose [task_definition contains
+the pragma]{task declaration specifies the aspect}.
+
+[A CPU pragma]{The CPU aspect} has no effect if it {is specified for a
+subprogram}[occurs immediately within the declarative_part of a subprogram_body]
+other than the main subprogram; the CPU value is not associated with any task.
+
+The CPU value is associated with the environment task if [the pragma appears in
+the declarative_part of]{the CPU aspect is specified for} the main subprogram.
+If [a pragma CPU does not apply to]{the CPU aspect is not specified for} the
+main subprogram it is implementation defined on which processor the environment
+task executes.
+
+===pragma Interrupt_Priority, Priority
+
+Add after D.1(5):
+
+Static Semantics
+
+The Priority and Interrupt_Priority representation aspects can be specified on a
+task_type_declaration, a single_task_declaration, a subprogram_declaration. The
+value of the aspects is an expression.
+
+The pragma Priority sets the Priority aspect of the enclosing task or subprogram
+to the expression. The pragma Interrupt_Priority sets the Interrupt_Priority
+aspect of the enclosing task or subprogram to the expression, if any. If there
+is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect
+has the value Interrupt_Priority'Last.
+
+Add to the end of D.1(6):
+
+When the aspect Priority or Interrupt_Priority is specified, the
+aspect_definition is an expression which is expected to be of type Integer.
+
+Delete the last sentence of D.1(7) [handled below]
+
+Replace D.1(8):
+
+If the Priority aspect is specified for a subprogram, the expression shall be static, and its value shall
+be in the range of System.Priority.
+
+Add after D.1(8):
+
+At most one of the Priority and Interrupt_Priority aspects may be specified for
+a given entity.
+
+AARM Ramification: This includes specifying via pragmas.
+
+Delete D.1(13). [This is covered by other wording.]
+
+Replace D.1(14):
+
+[A Priority pragma]{The Priority aspect} has no effect if it {is specified for a
+subprogram}[occurs immediately within the declarative_part of a subprogram_body]
+other than the main subprogram{; the Priority value is not associated with any
+task}.
+
+[Note: We added the last part as a clarification for CPU, it should be here,
+too.]
+
+Modify D.1(16):
+
+The effect of specifying [such a pragma in]{a Priority or Interrupt_Priority
+for} a protected_definition is discussed in D.3.
+
+Modify D.1(17):
+
+The expression [in a Priority or Interrupt_Priority pragma that appears in a
+task_definition]{specified for the Priority or Interrupt_Priority aspect of a
+task} is evaluated for each task object (see 9.1). For [a]{the} Priority
+[pragma]{aspect}, the value of the expression is converted to the subtype
+Priority; for [an]{the} Interrupt_Priority [pragma]{aspect}, this value is
+converted to the subtype Any_Priority. The priority value is then associated
+with the task object whose [task_definition contains the pragma]{task
+declaration specifies the aspect}.
+
+Modify D.1(18):
+
+Likewise, the priority value is associated with the environment task if the
+{aspect is specified for}[pragma appears in the declarative_part of] the main
+subprogram.
+
+Change "pragma" to "aspect" in D.1(19).
+
+Modify D.3(6/2):
+
+The expression [in a Priority or Interrupt_Priority pragma
+task_definition]{specified for the Priority or Interrupt_Priority aspect} (see
+D.1) is evaluated as part of the creation of the corresponding protected object
+and converted to the subtype System.Any_Priority or System.Interrupt_Priority,
+respectively. The value of the expression is the initial priority of the
+corresponding protected object. If no Priority or Interrupt_Priority [pragma
+applies to]{aspect is specified for} a protected object, the initial priority is
+specified by the locking policy.
+
+Replace "pragma" by "aspect" in D.3(8/2).
+
+Modify D.3(10/2):
+If an Interrupt_Handler or Attach_Handler [pragma]{aspect} (see C.3.1) [appears
+in a protected_definition]{is specified for a protected subprogram of a
+protected type that does not have the Interrupt_Priority aspect specified}[
+without an Interrupt_Priority pragma], the initial priority of protected objects
+of that type is implementation defined, but in the range of the subtype
+System.Interrupt_Priority.
+
+Replace D.3(11/2):
+If neither aspect Priority nor Interrupt_Priority is specified for a protected
+type, and no protected subprogram of the type has aspect Interrupt_Handler or
+Attach_Handler specified, then the initial priority of the corresponding
+protected object is System.Priority'Last.
+
+
+===pragma Implemented
+
+See AI05-0215-1. *** TBD: Ed Schonberg.
+
+===pragmas Convention, Export, Import:
+
+Modify B.1(28) as follows:
+
+ Import, Export, and Convention pragmas are representation pragmas that
+ specify the [c]{C}onvention aspect of representation{, using
+ /convention_/identifiers that are identifiers specific to the
+ Convention aspect}. In addition, Import and Export pragmas specify the
+ [imported]{Import} and [exported]{Export (boolean)} aspects of
+ representation, respectively{, along with the External_Name and
+ Link_Name (string) aspects}. {These aspects may also be specified
+ using an aspect_specification associated with the named entity, so
+ long as the Import and Export aspect are not both specified as True
+ for a single entity, and the External_Name or the Link_Name aspect are
+ specified only if the Import or Export aspect is specified as True.
+ [Redundant: In the absence of an interfacing pragma or an
+ aspect_specification for the Convention aspect, the Convention aspect
+ defaults to Ada for a user-declared entity, unless specified otherwise
+ in this International Standard (see 6.3.1).]}
+
+
+Rearrange Annex K:
+
+ Annex K
+ (informative)
+
+ Language-Defined Aspects and Attributes
+
+
+This annex summarizes the definitions given elsewhere of the language-defined
+aspects and attributes. Some aspects have corresponding attributes, as noted.
+
+
+K.1 Language-Defined Aspects
+
+...[etc]
+
+Precondition: Specifies a condition that must hold true in order to call a given
+ subprogram. See 13.3.1.
+
+Size: Size in bits of a subtype or object See 13.3.
+
+
+K.2 Language-Defined Attributes
+
+...[entire contents of old Annex K goes here.]
+
+
+
!discussion
+The intent is that all existing representation and operational aspects can
+be used in an aspect_specification.
+
+In addition, we would like to allow as many pragmas as possible to be
+treated as aspects. To make sense as an aspect, a pragma has to be restricted to
+the scope of the entity.
+
+It has to have two parameters, the first is the entity, the second a
+name/expression of some type, which is then the type of the aspect.
+
+Or, if the second argument is an "identifier specific to a pragma", it could
+make sense if we invent "identifiers specific to an aspect". [TBD in AI05-0183-1.]
+
+Or it could have just one parameter, the entity, and the type of the aspect is
+Boolean (True/False means the pragma is present/absent).
+
+Following is a list of all Ada pragmas, listed in
+
+----------------
+
+Boolean representation aspects:
+
+pragma Asynchronous(local_name); - See E.4.1.
+
+pragma Atomic(local_name); - See C.6.
+
+pragma Atomic_Components(array_local_name); - See C.6.
+
+pragma Controlled(first_subtype_local_name); - See 13.11.3.
+pragma Discard_Names[([On => ] local_name)]; - See C.5.
+
+pragma Independent(component_local_name); - See C.6.
+
+pragma Independent_Components(local_name); - See C.6.
+
+pragma Pack(first_subtype_local_name); - See 13.2.
+
+pragma Volatile(local_name); - See C.6.
+
+pragma Volatile_Components(array_local_name); - See C.6.
+
+pragma Unchecked_Union (first_subtype_local_name); - See B.3.3.
+
+Note: For representation pragmas, 13.1(8/3) specifies that the
+pragma specifies an aspect and the name of that aspect. Thus, we don't need
+any wording in these pragmas about "aspects of representation"; we get rid
+of extra such wording for consistency.
+
+----------------
+
+Pragmas that could be Boolean operational or representation aspects:
+
+pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3.
+
+pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1.
+
+pragma Inline(name {, name}); - See 6.3.2.
+
+pragma Interrupt_Handler(handler_name); - See C.3.1.
+
+pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1.
+
+pragma Preelaborable_Initialization(direct_name); - See 10.2.1.
+
+pragma Preelaborate[(library_unit_name)]; - See 10.2.1.
+
+pragma Pure[(library_unit_name)]; - See 10.2.1.
+
+pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3.
+
+pragma Remote_Types[(library_unit_name)]; - See E.2.2.
+
+pragma Shared_Passive[(library_unit_name)]; - See E.2.1.
+
+----------------
+
+Pragmas that could be other (normal) operational or representation aspects:
+
+pragma Attach_Handler(handler_name, expression); - See C.3.1.
+ -- Aspect type is Interrupts.Interrupt_ID.
+
+pragma CPU (expression); - See D.16.
+ -- Aspect type is System.Multiprocessors.CPU_Range.
+ -- And this implicitly applies to outer task/prot. or PROCEDURE!
+
+pragma Interrupt_Priority[(expression)]; - See D.1.
+ -- Aspect type is Integer.
+ -- Does the aspect have a default value? (no.)
+
+pragma Priority(expression); - See D.1.
+ -- Aspect type is Integer.
+ -- Require static in procedure?
+
+pragma Relative_Deadline (relative_deadline_expression); - See D.2.6.
+ -- Aspect type is Real_Time.Time_Span.
+
+pragma Storage_Size(expression); - See 13.3.
+ -- Aspect type is universal_integer?
+
+----------------
+
+Pragmas that could be other (normal) operational or representation aspects
+if we have a mechanism for "identifiers specific to an aspect":
+
+pragma Convention([Convention =>] convention_identifier,[Entity =>]
+local_name); - See B.1.
+ -- Note that the parameters are backwards
+
+pragma Implemented(procedure_local_name, implementation_kind); - See 9.5.
+
+pragma Export(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.
+ -- Only if split into multiple aspects.
+
+pragma Import(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.
+ -- Only if split into multiple aspects.
+
+----------------
+
+Make no sense as aspects:
+
+pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2.
+
+pragma Assertion_Policy(policy_identifier); - See 11.4.2.
+
+pragma Detect_Blocking; - See H.5.
+
+pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1.
+
+pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 10.2.1.
+
+pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2.
+
+pragma Linker_Options(string_expression); - See B.1.
+
+pragma List(identifier); - See 2.8.
+
+pragma Locking_Policy(policy_identifier); - See D.3.
+
+pragma Normalize_Scalars; - See H.1.
+
+pragma Optimize(identifier); - See 2.8.
+
+pragma Page; - See 2.8.
+
+pragma Partition_Elaboration_Policy (policy_identifier); - See H.6.
+
+pragma Priority_Specific_Dispatching (
+ policy_identifier, first_priority_expression, last_priority_expression);
+- See D.2.2.
+
+pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13.
+
+pragma Queuing_Policy(policy_identifier); - See D.4.
+
+pragma Restrictions(restriction{, restriction}); - See 13.12.
+
+pragma Reviewable; - See H.3.1.
+
+pragma Suppress(identifier); - See 11.5.
+
+pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2.
+
+pragma Unsuppress(identifier); - See 11.5.
+
+
+
!ACATS test
ACATS tests would be needed for this aspect.
@@ -1626,6 +2327,426 @@
Shrug. It seems simple enough to produce this annex.
I'm happy to write the words (if everybody (except me!) agrees that the RM
should weigh 50 pounds).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, February 8, 2011 2:21 PM
+
+Regarding AI05-0229-1, the minutes of the Jan 27, 2011 phone meeting say:
+
+> Summary of action items:
+> Bob:
+...
+> AI05-0229-1 - Work out the form and contents of the aspect annex clause
+> with Randy.
+...
+
+For "form", see below.
+
+For "content", I don't see the hurry. I think I should wait until we have a
+more settled list of them, with relevant semantics. I don't even know what they
+all are, at this point.
+
+As I said, I think it's easy: I plan to write an informal one-liner for each
+aspect to go in this (useless!) annex.
+
+> AI05-0229-1/01 Specifiable aspects
+
+> Tucker suggests that we could put them as two separate sections in
+> Annex K. That seems like a good idea as they are related. The title
+> will be challenge, but we can leave that to Bob. [I'm expecting a
+> title like "Useless listing of language-defined attributes and
+> aspects". :-) - Editor.]
+
+[The text here is part of version /02 of this AI. - Editor]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 12, 2011 12:27 AM
+
+...
+> For "content", I don't see the hurry. I think I should wait until we
+> have a more settled list of them, with relevant semantics. I don't
+> even know what they all are, at this point.
+
+I had wanted some examples for Draft 11. But since I didn't add this annex in
+that draft, you'll have until mid-March to provide the content.
+
+Keep in mind that we're supposed to finish all work on the standard at this
+upcoming meeting, and the next AARM draft will be going out for editorial and
+National Body review. The annex will need to be in that version.
+
+I don't plan to put the actual entries into the AI, just the standard.
+
+...
+> Precondition: Specifies a condition that must hold true in order to
+> call a given subprogram.
+
+The existing annexes include an (automated) cross-reference to the section of
+definition. We'll certainly do that here, too; that's kinda the point. So this
+will end with "See 13.3.1.". You'll need to keep that in mind as you write
+these.
+
+> Size: See attribute below.
+
+That wouldn't make any sense, with the automatic cross-reference.
+
+Size: See attribute below. See 13.3.
+
+!!!
+
+> Or maybe:
+>
+> Size: Size in bits of a subtype or object (see Size attribute below).
+
+Same here:
+
+Size: Size in bits of a subtype or object (see Size attribute below). See 13.3.
+
+The following would work, of course.
+
+Size: Size in bits of a subtype or object. See 13.3.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 10, 2011 2:43 AM
+
+...
+> And I finished the rest of my ARG homework, too, I think.
+
+Back on January 24th, you wrote:
+
+I have completed all of the above homework (yay!), except for AI05-0229-1.
+The Fairfax minutes say:
+
+ Bob will figure out the wording needed to allow Priority and CPU as
+ aspects.
+
+which I'm not sure how to approach. Rewrite the pragma Priority section to
+allow "task ... with Priority => ..."? And say something in general about how
+aspects can be misc pragmas not mentioned already in this AI?
+
+Maybe the CPU thing should be ONLY an aspect (since everybody seems to prefer
+aspects nowadays
+
+====
+
+You never did this. I'm happy to tell you how to approach it - just write the
+wording needed to augment/replace that for each pragma. I don't think there is
+any way to generalize it, and I don't see much point anyway.
+
+You'll also have to help me figure out what parts of your mail from last October
+belongs in this AI; I never considered it as approproate AI contents but since I
+don't seem to be getting anything else I guess I'll have to try to figure out
+how to turn it into something that makes sense as wording and AARM notes...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 11, 2011 9:05 AM
+
+> Maybe the CPU thing should be ONLY an aspect (since everybody seems to
+> prefer aspects nowadays
+
+Nobody answered this question. Should I submit a new version of AI05-0171-1,
+"Pragma CPU and Ravenscar Profile" with a different subject, and change the
+pragma into an aspect? That AI is currently ARG Approved.
+
+AI05-0167-1, "Managing affinities for programs executing on multiprocessors"
+refers to pragma CPU, so should I submit a new version of that AI, too?
+
+And if CPU is an aspect instead of a pragma, then should I change
+Dispatching_Domain (in AI05-0167-1) to also be an aspect?
+
+Are the latest versions of these AIs in the CVS repository?
+
+...
+> You'll also have to help me figure out what parts of your mail from
+> last October belongs in this AI; I never considered it as approproate
+> AI contents but since I don't seem to be getting anything else I guess
+> I'll have to try to figure out how to turn it into something that
+> makes sense as wording and AARM notes...
+
+Yes, please. I'm not the one pushing for everything under the sun to be turned
+into an aspect. I don't think it's feasible, so those who do should put up some
+wording. I did my best, but don't be surprised that what I did is incomplete.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 11, 2011 12:57 PM
+
+> Nobody answered this question. Should I submit a new version of
+> AI05-0171-1, "Pragma CPU and Ravenscar Profile" with a different
+> subject, and change the pragma into an aspect?
+> That AI is currently ARG Approved.
+
+That's fine, or you can just put new wording into AI05-0229-1. AIs can still be
+changed until they are WG 9 approved, so it is probably better that we go that
+way.
+
+> AI05-0167-1, "Managing affinities for programs executing on
+> multiprocessors" refers to pragma CPU, so should I submit a new
+> version of that AI, too?
+
+Sure.
+
+> And if CPU is an aspect instead of a pragma, then should I change
+> Dispatching_Domain (in AI05-0167-1) to also be an aspect?
+
+I think so.
+
+> Are the latest versions of these AIs in the CVS repository?
+
+Yes, with the possible exception of the AI-167 you sent the other day. I've
+filed it here, but I don't know if I've uploaded the changes since I did that.
+
+...
+> > You'll also have to help me figure out what parts of your mail from
+> > last October belongs in this AI; I never considered it as
+> > approproate AI contents but since I don't seem to be getting
+> > anything else I guess I'll have to try to figure out how to turn it
+> > into something that makes sense as wording and AARM notes...
+>
+> Yes, please. I'm not the one pushing for everything under the sun to
+> be turned into an aspect. I don't think it's feasible, so those who
+> do should put up some wording. I did my best, but don't be surprised
+> that what I did is incomplete.
+
+OK. We can do that off-line (no need to clutter this list with discussions of AI
+formats).
+
+****************************************************************
+
+From: Alan Burns
+Sent: Saturday, February 12, 2011 6:01 AM
+
+I've not been following the discussions about aspects, so I'm not sure what the
+consequences are for changing from a pragma to an aspect - but for us real-time
+folk a consistent language style is what we most need. We already have pragmas
+for priority, profiles and initial deadline, so can we not also have pragmas for
+affinities?
+
+Or are all these other pragmas also changing?
+
+In telling people about the support that Ada provides for multicores I would
+prefer not to have to also talk about changes to the things they already know
+(unless the change to aspect in just a pure syntax change).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 12, 2011 8:22 PM
+
+> I've not been following the discussions about aspects, so I'm not sure
+> what the consequences are for changing from a pragma to an aspect -
+> but for us real-time folk a consistent language style is what we most
+> need.
+> We already have pragmas for priority, profiles and initial deadline,
+> so can we not also have pragmas for affinities?
+>
+> Or are all these other pragmas also changing?
+
+Virtually all pragmas will be also available in aspect form. In new code,
+aspects will be preferred (at least IMHO).
+
+> In telling people about the support that Ada provides for multicores I
+> would prefer not to have to also talk about changes to the things they
+> already know (unless the change to aspect in just a pure syntax
+> change).
+
+There is no semantic difference between specifying properties with attributes,
+pragmas, or aspects. So it is just a syntax change.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, February 14, 2011 7:54 AM
+
+> Virtually all pragmas will be also available in aspect form. In new
+> code, aspects will be preferred (at least IMHO).
+
+Can I put in a plea for both forms being available with multiprocessor pragmas
+(ie not just aspects)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 12, 2011 7:29 AM
+
+> ...
+> > For "content", I don't see the hurry. I think I should wait until
+> > we have a more settled list of them, with relevant semantics. I
+> > don't even know what they all are, at this point.
+>
+> I had wanted some examples for Draft 11. But since I didn't add this
+> annex in that draft, you'll have until mid-March to provide the content.
+
+Well, I've given several off-the-cuff examples in the past.
+
+How about you give me a macro format, and a list of aspects, and I'll write them
+all up? If your list is incomplete, I'll complete it later. I'll give you
+something like:
+
+ After 1.2.3(45):
+ @aspect-index-entry{Precondition|Specifies a condition that must
+ hold true in order to call a given subprogram.}
+
+(or whatever the correct macro-call syntax is -- I assume it's still vaguely based on Scribe). The macro will automatically generate an entry in the Annex, including the section number, plus an entry in the index.
+
+Tell me whether you want the macro call before, after, or part of the relevant
+paragraph.
+
+> Keep in mind that we're supposed to finish all work on the standard at
+> this upcoming meeting, and the next AARM draft will be going out for
+> editorial and National Body review. The annex will need to be in that version.
+>
+> I don't plan to put the actual entries into the AI, just the standard.
+>
+> ...
+> > Precondition: Specifies a condition that must hold true in order to
+> > call a given subprogram.
+>
+> The existing annexes include an (automated) cross-reference to the
+> section of definition. We'll certainly do that here, too; that's kinda
+> the point. So this will end with "See 13.3.1.". You'll need to keep
+> that in mind as you write these.
+>
+> > Size: See attribute below.
+>
+> That wouldn't make any sense, with the automatic cross-reference.
+>
+> Size: See attribute below. See 13.3.
+>
+> !!!
+
+OK, then:
+
+Size (also attribute). See 13.3.
+
+And the intro would say "Some aspects are also attributes, as noted, see
+Whatever.
+
+> > Or maybe:
+> >
+> > Size: Size in bits of a subtype or object (see Size attribute below).
+>
+> Same here:
+>
+> Size: Size in bits of a subtype or object (see Size attribute below).
+> See 13.3.
+
+If you insist on defining every attribute THREE times, then:
+
+Size: Size in bits of a subtype or object (same as Size attribute).
+See 13.3.
+
+> The following would work, of course.
+>
+> Size: Size in bits of a subtype or object. See 13.3.
+
+Don't you think it's useful to say which aspects are also attributes or pragmas?
+(Preferably instead of describing them, but in addition, if you insist.)
+
+In that case, how about 3 macros, one for aspects that are also pragams, one for
+also-attrs, and one for the rest? They can generate appropriate canned text,
+such as " (also an attribute)".
+
+Actually, forget the pragma one -- we want people to switch entirely over to the
+aspect. But attributes are still useful as queries.
+
+Here's another idea (sorry for the stream-of-conciousness e-mail!):
+
+Size: X'Size is the size in bits of subtype or object X.
+See 13.3.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 12, 2011 8:10 AM
+
+> How about you give me a macro format, and a list of aspects, and I'll
+> write them all up? If your list is incomplete, I'll complete it
+> later. I'll give you something like:
+>
+> After 1.2.3(45):
+> @aspect-index-entry{Precondition|Specifies a condition that must
+> hold true in order to call a given subprogram.}
+>
+> (or whatever the correct macro-call syntax is -- I assume it's still
+> vaguely based on Scribe). The macro will automatically generate an
+> entry in the Annex, including the section number, plus an entry in the
+> index.
+
+That's fine, although just pairs (aspect, description) would be enough.
+
+Looking at the existing commands, I think we'll have something like
+
+@chgaspectdesc{Version=[<version>],Kind=[<kind>],Aspect=[<text>],Text=[<text
+>]}
+
+(So we have everything we'll need going forward.) For this version, that will
+look like:
+
+@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Precondition],
+Text=[Specifies a condition that must hold true in order to call a given subprogram.]}
+
+The first two items will be the same for all of these.
+
+> Tell me whether you want the macro call before, after, or part of the
+> relevant paragraph.
+
+I think after (like @ImplDef and @ChgImplDef).
+
+...
+> If you insist on defining every attribute THREE times, then:
+>
+> Size: Size in bits of a subtype or object (same as Size attribute).
+> See 13.3.
+
+This isn't a definition, it's a reference list.
+
+> > The following would work, of course.
+> >
+> > Size: Size in bits of a subtype or object. See 13.3.
+>
+> Don't you think it's useful to say which aspects are also attributes
+> or pragmas? (Preferably instead of describing them, but in addition,
+> if you insist.)
+
+I don't see the point off-hand, but I could be convinced.
+
+The typical use for this annex is when you are looking for an aspect that you
+want to specify whose name you don't remember. Whether or not it can be queried
+with an attribute isn't terribly relevant to that. If you know the name, you'd
+probably use the main index or the search page. It's only when you don't know
+the name that these lists come in handy.
+
+One can imagine that the list of aspects is of things that you can specify; the
+list of attributes is of things you can query. These seem like disjoint lists to
+me.
+
+> In that case, how about 3 macros, one for aspects that are also
+> pragams, one for also-attrs, and one for the rest?
+> They can generate appropriate canned text, such as " (also an
+> attribute)".
+
+Sounds like overkill to me.
+
+> Actually, forget the pragma one -- we want people to switch entirely
+> over to the aspect. But attributes are still useful as queries.
+>
+> Here's another idea (sorry for the stream-of-conciousness e-mail!):
+>
+> Size: X'Size is the size in bits of subtype or object X.
+> See 13.3.
+
+I suppose that would work. Still doesn't seem necessary to me. Does anyone else
+have an opinion about whether these entries should include information about the
+associated pragma or attribute?
****************************************************************
Questions? Ask the ACAA Technical Agent