!standard 1.1.3(17) 11-10-14 AI05-0229-1/14 !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) !standard 6.3.2(5) !standard 6.3.2(6) !standard 6.3.2(6.1/2) !standard 6.3.2(7) !standard 6.5.1(1/2) !standard 6.5.1(2/2) !standard 6.5.1(3/2) !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) !standard 13.3(61) !standard 13.3(62) !standard 13.3(63) !standard 13.3(64) !standard 13.3(65) !standard 13.3(66) !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) !standard 13.11.3(4) !standard 13.11.3(5) !standard 13.11.3(6) !standard 13.11.3(7) !standard 13.11.3(8) !standard 13.12.1(4/2) !standard A.1(37) !standard A.1(42) !standard A.1(42.1/2) !standard B.1(1) !standard B.1(2) !standard B.1(4) !standard B.1(5) !standard B.1(6) !standard B.1(7) !standard B.1(9.1/1) !standard B.1(10) !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) !standard B.3(39.5/2) !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) !standard B.3.3(4/2) !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) !standard C.3.1(4) !standard C.3.1(5) !standard C.3.1(6) !standard C.3.1(7/2) !standard C.3.1(9) !standard C.3.1(10) !standard C.3.1(11/2) !standard C.3.1(12/1) !standard C.3.1(14.1/1) !standard C.3.1(17) !standard C.3.1(19) !standard C.3.1(22) !standard C.3.2(17) !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) !standard D.1(4) !standard D.1(5) !standard D.1(6) !standard D.1(7) !standard D.1(8) !standard D.1(13) !standard D.1(14) !standard D.1(16) !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) !standard D.2.6(5/2) !standard D.2.6(6/2) !standard D.2.6(9/2) !standard D.2.6(12/2) !standard D.2.6(13/2) !standard D.3(6.1/2) !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) !standard E.2.3(16) !standard E.2.3(19/1) !standard E.4.1(1) !standard E.4.1(2) !standard E.4.1(3) !standard E.4.1(4) !standard E.4.1(5) !standard E.4.1(6) !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.9(3/2) !standard J.15(0) !standard J.15.1(0) !standard J.15.2(0) !standard J.15.3(0) !standard J.15.4(0) !standard J.15.5(0) !standard J.15.6(0) !standard J.15.7(0) !standard J.15.8(0) !standard J.15.9(0) !standard J.15.11(0) !standard J.15.12(0) !standard J.15.13(0) !standard K.1(0) !class Amendment 10-10-25 !status Amendment 2012 11-06-06 !status ARG Approved (by Letter Ballot) 9-1-1 11-05-16 !status work item 10-10-25 !status received 10-10-25 !priority Medium !difficulty Easy !subject Specifiable aspects !summary (See proposal.) !problem 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 Replace the sixth paragraph from the end of the Static Semantics in AI05-0183-1/11 (13.3.1(30/3) in draft 11.5): All specifiable operational and representation attributes may be specified with an aspect_specification instead of an attribute_definition_clause (see 13.3). AARM Ramification: The name of the aspect is the same as that of the attribute (see 13.3), so the aspect_mark is the name of the attribute. [Editor's Note: 13.3(5/3), from AI05-0183-1; but we can't put paragraph numbers into AARM notes. We need this note here because this rule is far away in the standard.] Any aspect specified by a representation pragma or library unit pragma that has a local_name as its single argument 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. AARM Ramification: The name of the aspect is the same as that of the pragma (see 13.1), so the aspect_mark is the name of the pragma. [Editor's Note: 13.1(8/3), from AI05-0112-1; but we can't put paragraph numbers into AARM notes. We need this note here because this rule is far away in the standard.] [Editor's notes: The "=> True" part may 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. This rule is mostly for the pragmas that are now moved to Annex J. We might consider moving this to Annex J as well - but we're not going to do that for the definition of representation pragmas in 13.1 (as it is too hard to extract) - so it OK to leave it here as well. Any preference??] In addition, other operational and representation aspects not associated with specifiable attributes or representation pragmas may be specified, as specified elsewhere in this International Standard. Modify 13.12.1(4/2): No_Obsolescent_Features There is no use of language features defined in Annex J. It is implementation[-]{ }defined {whether}[if] uses of the renamings of J.1 {and of the pragmas of J.15} are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition. AARM Note: The pragmas have exactly the functionality of the corresponding aspect, (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). ===pragma Pack: (the pragma is to be obsolescent) Change the title of clause 13.2 to "Packed types". [Editor's note: Could have used "Aspect Pack" instead, but this seems more meaningful, and more like the inline clause. Similar comments apply to all of the other clauses that were named "pragma Something".] Change "packing" to "Pack" in 13.3(55.e), 13.3(73), 13.3(73.a), 13.1(7.g), 9.10(1/3), 9.10(1.c), 13.6(1). [Note: We're only changing uses where "packing is specified" or the like.] Modify 13.2(1): [Redundant: {The Pack aspect having the value True}[A pragma Pack] specifies that storage minimization should be the main criterion when selecting the representation of a composite type.] Delete 13.2(2-4). [Now in Annex J.] Replace 13.2(5): For a full type declaration of a composite type, the following language-defined representation aspect may be specified: Pack The type of aspect Pack is Boolean. When aspect Pack is True for a type, 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 specifying Pack causes packing only of the extension part. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False. [Editor's Note: We say "full type declaration" in order to encapsulate all of the rules about requiring a "first subtype" and not a partial view. This is somewhat redundant with the rules in 13.1 for representation aspects, but it seems good to be clear.] Modify AARM 13.2(6.a): {Specifying the Pack aspect}[A pragma Pack] is for gaining space efficiency, possibly at the expense of time. If more explicit control over representation is desired, then a record_representation_clause, a Component_Size clause, or a Size clause should be used instead of, or in addition to, {the Pack aspect}[a pragma Pack]. Modify 13.2(7): The recommended level of support for {the Pack aspect}[pragma Pack] is: Modify AARM Notes 13.2(9.b-d/2), replacing "pragma Pack" with "the Pack aspect". Modify A.1(37) to use the Pack aspect rather than the pragma: type String is array(Positive range <>) of Character{ with Pack}; [ pragma Pack(String);] Modify A.1(42), A.1(42.1/2), B.4(12), B.4(16), B.4(20), B.4(29), B.5(12) to use the Pack aspect rather than the pragma as described above. In B.3(23), delete "pragma Pack" (it is bogus to have both Pack and Component_Size specified for the same type; Pack is ineffective in that case). Add "with Pack" to B.3(33), B.3(39.5/2), and B.3(39.14/2). Delete B.3(34), B.3(39.6/2), and B.3(39.15/2) [which are just pragma Pack]. Modify C.6(21): If [a pragma Pack applies to]{the Pack aspect is True for} a type any of ... AARM notes in 13.1 and 13.3 need modification from "pragma Pack" to "aspect Pack". ===pragma No_Return (the pragma is to be obsolescent) Change the title of clause 6.5.1 to "Non-returning Procedures". Modify 6.5.1(1/2): {Specifying aspect No_Return to have the value True}[A pragma No_Return] indicates that a procedure cannot return normally [Redundant:; it may propagate an exception or loop forever]. Delete 6.5.1(2-3/2). [Now in Annex J.] Add before 6.5.1(4/2): Static Semantics For a procedure or generic procedure, the following language-defined representation aspect may be specified: No_Return The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be *non-returning*. If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False. Move 6.5.1(8/2) to this point (keeping the Static Semantics together). Replace 6.5.1(4/2): [Start of Legality Rules] Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit. Modify 6.5.1(10/2): procedure Fail(Msg : String)[;]; -- raises Fatal_Error exception with No_Return;} [pragma No_Return(Fail);] -- Inform compiler and reader that procedure never returns normally Modify 11.4.1(4/2): procedure Raise_Exception(E : in Exception_Id; Message : in String := ""){ with No_Return}; [pragma No_Return(Raise_Exception);] [This is the only use of No_Return in an Ada predefined package.] ===pragma Controlled: Delete the entire subclause 13.11.3. Remove "(see 13.11.3)" from 4.8(15). ===pragma Unchecked_Union: (the pragma is to be obsolescent) Change the title of clause B.3.3 to "Unchecked Union Types". Modify B.3.3(1/2): [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*. Delete B.3.3(29/2) (pragma Controlled has been removed). ===pragma Discard_Names: [Editor's note: Can't get make this pragma obsolescent; its use as a configuration pragma or to apply to all entities in a package specification cannot be modeled as an aspect. C.5: No changes needed for Discard_Names; the general wording for using representation pragmas as aspects applies here. But note that this is the only remaining representation pragma in the core. 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.] ===pragma Atomic, Atomic_Components, Independent, 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 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. 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 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, or a component of an array for which the aspect Atomic_Components is True for the associated type, or any object of an atomic type, other than objects obtained by evaluating a slice. A volatile type is one for which the aspect Volatile is True. A Volatile object (including a component) is one for which the aspect Volatile is True, or a component of an array for which the aspect Volatile_Components is True for the associated type, or any object of a volatile type. In addition, every atomic type or object is also defined to be volatile. Finally, if an object is volatile, then so are all of its subcomponents. 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 or components 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: If aspect Independent_Components is specified for a full_type_declaration, the declaration shall be that of an array or record type. [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 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 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 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 specified directly on the constant object and not when the (named) array type has the aspect. It is illegal to specify the aspect Independent or Independent_Components as True for a component, object or type if the implementation cannot provide the independent addressability required by the aspect (see 9.10). It is illegal to specify a representation aspect for a component, object or type for which the aspect Independent or Independent_Components is True, in a way that prevents the implementation from providing the independent addressability required by the aspect. Delete C.6(14) [Now in Annex J.] Delete C.6(14.1/3) (moved above). 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) 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): 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: [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. ===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 [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 the pragma 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. Modify E.2.3(19/1): If [a pragma]{aspect} All_Calls_Remote [applies to]{is True for} a given RCI library unit, ... ===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 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. 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.] Replace 6.3.2(5) with For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified: Inline The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram. If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False. Modify 6.3.2(6): For each call, an implementation is free to follow or to ignore the recommendation {determined}[expressed] by the {Inline aspect}[pragma]. Delete 6.3.2(6.1/2). Delete AARM Notes 6.3.2(5.a-5.c) [but not 5.d], 6.3.2(6.b-c/2). Delete 6.3.2(7). Replace Inline in 2.8(29/2): pragma Pure(Rational_Numbers); -- Set the categorization of package Rational_Numbers (see 7.1) Modify the last sentence of 10.1.4(7/2): If the given compilation unit contains the body of a subprogram {for}[to] which {aspect}[a @fa] Inline {is True}[applies], the implementation may also remove any compilation unit containing a call to that subprogram. Modify 11.5(7.2/2): "...to a subprogram {for which aspect}[that has a pragma] Inline {is True}[applied to it],..." Modify 11.6(6): "..., and {for which the}[has no] Inline {aspect is False}[pragma applied to it]. ..." Modify 13.8(13): M : Mask; procedure Set_Mask{ with Inline};[ pragma Inline(Set_Mask);] Other pragmas: ===pragma Preelaborable_Initialization (referred to as P_I below) [Editor's Note: This pragma does not work well as a type-related aspect, as it is view dependent. In particular, even if a partial view does not have the P_I property, the full view might have the P_I property. That is contrary to 13.1(11/2) for operational and representation aspects. (In the absence of a change to 13.1(11/2), we'd have a compatibility problem.) We could try to invent new rules specifically for the P_I aspect to handle this, but it is more work than this could possibly be worth (there is no requirement for this pragma to be an aspect). Thus we are retaining the pragma and not defining an aspect.] ===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent) Delete C.3.1(1-6) [Now in Annex J.] Insert before C.3.1(7/3): Static Semantics For a parameterless protected procedure, the following language-defined representation aspects may be specified: Interrupt_Handler The type of aspect Interrupt_Handler is Boolean. If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False. Attach_Handler The aspect Attach_Handler is an expression, which shall be of type Interrupts.Interrupt_Id. [Redundant: This aspect is never inherited.] Delete C.3.1(7/3). [Also in Annex J.] Add after C.3.1(7/3): If either the Attach_Hander or Interrupt_Handler aspect are specifed for a protected procedure, 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), this rules also apply in the private part of an instance of a generic unit. Replace C.3.1(9): If the Interrupt_Handler aspect of a protected procedure is True, then the procedure may be attached dynamically, as a handler, to interrupts (see C.3.2). [Redundant: Such procedures are allowed to be attached to multiple interrupts.] [Editor's note: We change "can" to "may" to eliminate a banned word in ISO standards, here and elsewhere in this clause.] Replace C.3.1(10): The expression specified for the Attach_Handler aspect of a protected procedure P is evaluated as part of the creation of the protected object that contains P. The value of the expression identifies an interrupt. As part of the initialization of that object, P (the @fa procedure) is attached to the identified 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 {that contains a protected procedure} for which either {the}[an] Attach_Handler {aspect is specified} or {the} Interrupt_Handler [pragma applies to]{aspect is True}[ one of its procedures], a check is made that the {initial} ceiling priority {of the object (see D.3)}[defined in the protected_definition] is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True for one of its procedures, a check is made that the initial ceiling priority of the object 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]{aspects} are allowed to be used for other, implementation defined, forms of interrupt handlers. Modify C.3.1(22): The Attach_Handler {aspect may}[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 (the pragma is to be obsolescent) [Editor's 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). My presumption is that this explicit wording overrides the "automatic" aspect implied by the obsolescent attribute. I handled this with a pair of AARM notes, since I don't want to rewrite the wording of an obsolescent attribute nor rewrite the aspect_specification wording for this unusual case.] 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 For a task type (including the anonymous type of a single_task_declaration), the following language-defined representation aspect may be specified: Storage_Size The aspect Storage_Size is an expression, which shall be of any integer type. [Editor's note: I would have used the shorter wording "single task", but that term is not defined by the Standard. We do use it in a few AARM notes, but that isn't much help. Thus I used the longer wording.] AARM To Be Honest: This definition somewhat conflicts with the "automatic" one for the obsolescent attribute Storage_Size. We intend for that "automatic" one to not be used for that attribute. [Editor's note: Task types cannot be derived, so we don't have to worry about aspect inheritance, other than from task interfaces (a new possibility). We make those illegal (they can't be useful). The inabilility to derive also means we cannot run afoul of 13.1(10).] Delete 13.3(62-65) [Now in Annex J.] Add after 13.3(65): Legality Rules The Storage_Size aspect shall not be specified for a task interface type. Replace 13.3(66) with: When a task object is created, the expression (if any) associated with the Storage_Size aspect of its type is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the expression. AARM Ramification: If the Storage_Size aspect is not specified for the type of the task object, the value of the Storage_Size attribute is unspecified. Add to J.9(3/2): When the attribute is specified, the Storage_Size aspect is specified to be the value of the given expression. Add after J.9(3/2): AARM Ramification: When this attribute is specified with an attribute_definition_clause, the associated aspect is set to the value of the expression given in the attribute_definition_clause, rather than the expression itself. This value is therefore the same for all objects of the type; in particular, it is not re-evaluated when objects are created. This is different than when the aspect is specified with an aspect_specification (see 13.3). ===pragma Interrupt_Priority, Priority (the pragmas are to be obsolescent) [Editor's Note: I'd much prefer that there was only one aspect here, probably named "Base_Priority", but the rules about converting to subtype Any_Priority vs. to subtype Priority at evaluation time force two aspects. That's because these aspects are expressions that are evaluated when the task (or protected) object is elaborated, not values evaluated at the freezing point. Personally, I'd drop the two subtypes, but one presumes that there is some value to the bifrucation and in any case it is 30 years too late for that.] Delete D.1(2-7) [Moved to Annex J.] Add after D.1(5): Static Semantics For a task type (including the anonymous type of a single_task_declaration), protected type (including the anonymous type of a single_protected_declaration), or subprogram, the following language-defined representation aspects may be specified: Priority The aspect Priority is an expression, which shall be of type Integer. Interrupt_Priority The aspect Interrupt_Priority is an expression, which shall be of type Integer. [Editor's Note: See the comment about "single task" in Storage_Size.] [Editor's note: Task types and protected types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from synchronized interfaces (which we don't allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).] 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 (see J.15.11). Neither of the Priority or Interrupt_Priority aspects shall be specified for a synchronized interface type. Delete D.1(13). [This is covered by other wording, and seems to conflict with D.1(17) anyway. The definition of the value of the pragma is never used anywhere, so far as I can tell.] 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}. [Editor's Note: We added the last part as a clarification for aspect CPU, it should be here, too.] Modify D.1(16): The effect of specifying [such a pragma in a protected_definition]{a Priority or Interrupt_Priority aspect for a protected type or single_protected_declaration} 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 Relative_Deadline (the pragma is to be obsolescent) Delete D.2.6(3-6/2) [Now in Annex J.] Add after D.2.6(9/2): For a task type (including the anonymous type of a single_task_declaration) or subprogram, the following language-defined representation aspect may be specified: Relative_Deadline The aspect Relative_Deadline is an expression, which shall be of type Real_Time.Time_Span. [Editor's Note: See the comment about "single task" in Storage_Size.] Legality Rules The Relative_Deadline aspect shall not be specified on a task interface type. [Editor's note: Task types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from task interfaces (which we don't want to allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).] Replace D.2.6(12/2): 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 aspect}[containing pragma] Relative_Deadline {is specified} is the value of Real_Time.Clock + [relative_deadline_]expression{ that is the value of the aspect}, where {this entire expression, including }the call of Real_Time.Clock{, is evaluated} [is made] between task creation and the start of its activation. If {the aspect} [there is no] Relative_Deadline {is not specified}[pragma] 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{, using the value of the Relative_Deadline aspect of the main subprogram (if any)}. [Editor's note: The original wording did not specify when the deadline expression is evaluated. Since it is per-object, it also has to be evaluated when the task is created (roughly).] ===pragma CPU (the pragma is to be born obsolescent) Delete D.16(7-9/3) [Now in Annex J.] Add after D.16(9/3): Static Semantics For a task type (including the anonymous type of a single_task_declaration) or subprogram, the following language-defined representation aspect may be specified: CPU The aspect CPU is an expression, which shall be of type System.Multiprocessors.CPU_Range. [Editor's Note: See the comment about "single task" in Storage_Size.] [Editor's note: Task types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from task interfaces (which we don't allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).] Delete D.16(10/3). [Now in Annex J.] Replace D.16(11/3) with: If the CPU aspect is specified for a subprogram, the expression shall be static. The CPU aspect shall not be specified on a task interface type. Modify D.16(12-4/3): The expression [of a CPU pragma that appears in a task_definition]{specifed for 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 Dispatching_Domain (the pragma is to be born obsolescent) See AI05-0167-1 for the aspect. ===pragma Implemented (there will not be a pragma) See AI05-0215-1. ===pragmas Convention, Export, Import: (the pragmas are to be obsolescent) Rewrite B.1 as follows: [Editor's note: Some parts of this are unchanged.] B.1 Interfacing Aspects An /interfacing/ aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention. Specifying aspect Import to have the value True is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, specifying aspect Export to have the value True is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The Import and Export aspects are intended primarily for objects and subprograms, although implementations are allowed to support other entities. The Link_Name and External_Name aspects are used to specify the link name and external name, respectively, to be used to identify imported or exported entities in the external environment. The Convention aspect is used to indicate that an Ada entity should use the conventions of another language. It is intended primarily for types and “callback” subprograms. For example, “with Convention => Fortran” on the declaration of an array type Matrix implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order. A pragma Linker_Options is used to specify the system linker parameters needed when a given compilation unit is included in a partition. Syntax The form of a pragma Linker_Options is as follows: pragma Linker_Options(string_expression); A pragma Linker_Options is allowed only at the place of a declarative_item. Name Resolution Rules The Import and Export aspects are of type Boolean. The Link_Name and External_Name aspects are of type String. The expected type for the string_expression in pragma Linker_Options, is String. Legality Rules The aspect Convention shall be specified by a /convention_/identifier, which shall be the name of a convention. The convention names are implementation defined, except for certain language-defined ones, such as Ada and Intrinsic, as explained in 6.3.1, “Conformance Rules”. Additional convention names generally represent the calling conventions of foreign languages, language implementations, or specific run-time models. The convention of a callable entity is its calling convention. If L is a convention_identifier for a language, then a type T is said to be compatible with convention L, (alternatively, is said to be an L-compatible type) if any of the following conditions are met: T is declared in a language interface package corresponding to L and is defined to be L-compatible (see B.3, B.3.1, B.3.2, B.4, B.5), Convention L has been specified for T, and T is eligible for convention L; that is: T is an array type with either an unconstrained or statically-constrained first subtype, and its component type is L-compatible, T is a record type that has no discriminants and that only has components with statically-constrained subtypes, and each component type is L-compatible, T is an access-to-object type, its designated type is L-compatible, and its designated subtype is not an unconstrained array subtype, T is an access-to-subprogram type, and its designated profile's parameter and result types are all L-compatible. T is derived from an L-compatible type, The implementation permits T as an L-compatible type. If the Convention aspect is specified for a type, then the type shall either be compatible with or eligible for the specified convention. Notwithstanding any rule to the contrary, a declaration with a True Import aspect shall not have a completion. An entity with a True Import aspect (or Export aspect) is said to be imported (respectively, exported). An entity shall not be both imported and exported. The declaration of an imported object shall not include an explicit initialization expression. Default initializations are not performed. The type of an imported or exported object shall be compatible with the specified Convention aspect, if any. For an imported or exported subprogram, the result and parameter types shall each be compatible with the specified Convention aspect, if any. 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. Static Semantics 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: * 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. 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 for referring to an entity that an Ada program exports. A link name is a string value for the name of an exported or imported entity, based on the conventions of the foreign language's compiler in interfacing with the system's linker tool. The meaning of link names is implementation defined. If neither a link name nor the Address attribute of an imported or exported entity is specified, then a link name is chosen in an implementation-defined manner, based on the external name if one is specified. Pragma Linker_Options has the effect of passing its string argument as a parameter to the system linker (if one exists), if the immediately enclosing compilation unit is included in the partition being linked. The interpretation of the string argument, and the way in which the string arguments from multiple Linker_Options pragmas are combined, is implementation defined. Dynamic Semantics 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. Erroneous Execution It is the programmer's responsibility to ensure that the use of interfacing aspects does not violate Ada semantics; otherwise, program execution is erroneous. Implementation Advice If an implementation supports Export for 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. Automatic elaboration of preelaborated packages should be provided when specifying Export as True is supported. For each supported convention L other than Intrinsic, an 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. NOTES 1 Implementations may place restrictions on interfacing aspects; for example, requiring each exported entity to be declared at the library level. 2 The Convention aspect in combination with the Import aspect indicates the conventions for accessing external entities. It is possible that the actual entity is written in assembly language, but reflects the conventions of a particular language. For example, "with Convention => Ada" can be used to interface to an assembly language routine that obeys the Ada compiler's calling conventions. 3 To obtain “call-back” to an Ada subprogram from a foreign language environment, the Convention aspect should be specified both for the access-to-subprogram type and the specific subprogram(s) to which 'Access is applied. [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”. 7 If both External_Name and Link_Name are specified for a given entity, then the External_Name is ignored. Examples Example of interfacing aspects: package Fortran_Library is function Sqrt (X : Float) return Float with Import => True, Convention => Fortran; function Exp (X : Float) return Float with Import => True, Convention => Fortran; end Fortran_Library; In B.3(1/2), B.4(1), and B.5(1) change "the Import, Export and Convention pragmas" to "the Convention aspect" (the aspects Import and Export don't imply a convention). B.4(99), change "pragmas" to "aspects". In B.3(60.13/1), B.3(61/1), B.4(92), and B.5(20) change "pragma Convention" to "the aspect Convention". In B.4(106, 107, 115) and B.5(30), replace the pragmas with equivalent aspects. Replace B.3(62.1-62.4/3) with: An implementation need not support specifying the Convention aspect 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; * 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): 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 shall 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 is specified to have convention_identifier Fortran for". Delete B.3.2(12); in B.3.2(10-11), add "with Convention => Intrinsic" to each declaration. In 13.7.2(4), delete the pragmas, in 13.7.2(3), add "with Convention => Intrinsic" to each function. In 13.7.1(11), delete the pragmas, in 13.7.1(7, 8, 10), add "with Convention => Intrinsic" to each function (7). In B.2(11.1/2), replace "pragma" by "aspect". 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(18.2/2), 13.7(14), F.2(6). Add a new clause to Annex J: [Note: The subclauses are rearranged in alphabetical order in the core, then for each Annex. 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 Pragmas can be used as an alternative to aspect_specifications to specify certain aspects. J.15.1 Pragma Inline Syntax The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows: pragma Inline(name {, name}); Legality Rules The pragma shall apply to one or more callable entities or generic subprograms. [Editor's Note: "apply" comes from the definition of program unit pragma. Alternatively, we could have said: "The name of a pragma Inline shall apply to one or more callable entities or generic subprograms that may have aspect Inline specified." which allows us to depend on the Legality Rules of the aspect. In that case, we'd want to swap the Legality Rules and Static Semantics sections. I didn't do this because it is more wordy than just repeating the only Legality Rule of the aspect.] Static Semantics Pragma Inline specifies that the Inline aspect (see 6.3.2) for each entity denoted by each name given in the pragma has the value True. [Editor's note: The following AARM notes are moving from 6.3.2 to here.] AARM Ramification: Note that inline expansion is desired no matter what name is used in the call. This allows one to request inlining for only one of several overloaded subprograms as follows: package IO is procedure Put(X : in Integer); procedure Put(X : in String); procedure Put(X : in Character); private procedure Character_Put(X : in Character) renames Put; pragma Inline(Character_Put); end IO; with IO; use IO; procedure Main is I : Integer; C : Character; begin ... Put(C); -- Inline expansion is desired. Put(I); -- Inline expansion is NOT desired. end Main; Implementation Permissions An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part. AARM Reason: This is allowed for Ada 83 compatibility. This is only a permission as this usage is considered obsolescent. AARM Discussion: We only need to allow this in declarative_parts, because a body is only allowed in another body, and these all have declarative_parts. NOTES The name in a pragma Inline may denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities. J.15.2 Pragma No_Return Syntax The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows: pragma No_Return(procedure_local_name{, procedure_local_name}); Legality Rules Each procedure_local_name shall denote one or more procedures or generic procedures. [Redundant: The procedure_local_name shall not denote a null procedure nor an instance of a generic unit.] Static Semantics Pragma No_Return specifies that the No_Return aspect (see 6.3.2) for each procedure denoted by each local_name given in the pragma has the value True. J.15.3 Pragma Pack Syntax The form of a pragma Pack, which is a representation pragma (see 13.1), is as follows: pragma Pack(*first_subtype_*local_name); Legality Rules The first_subtype_local_name of a pragma Pack shall denote a composite subtype. Static Semantics Pragma Pack specifies that the Pack aspect (see 13.2) for the type denoted by *first_subtype_*local_name has the value True. J.15.4 pragma Storage_Size Syntax The form of a pragma Storage_Size is as follows: pragma Storage_Size(expression); A pragma Storage_Size is allowed only immediately within a task_definition. Name Resolution Rules The expression of a pragma Storage_Size is expected to be of any integer type. Static Semantics The pragma Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma. J.15.5 Interfacing pragmas An interfacing pragma is a representation pragma that is one of the pragmas Import, Export, or Convention. Their forms are as follows: pragma Import( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]); pragma Export( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]); pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name); For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given. Name Resolution Rules The expected type for a external_name_string_expression and a link_name_string_expression in an interfacing pragma is String. Legality Rules 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. 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. The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified. Static Semantics An interfacing pragam specifies various aspects of the entity denoted by the local_name as follows: * The Convention aspect (see B.1) is convention_identifier. * A pragma Import specifies that the Import aspect (see B.1) is True. * A pragma Export specifies that the Export aspect (see B.1) is True. * For both pragma Import and Export, if an external name is given in the pragma, the External_Name aspect is specified to be external_name_string_expression. If a link name is given in the pragma, the Link_Name aspect is specified to be the link_name_string_expression. J.15.6 Pragma Unchecked_Union Syntax The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), 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 specifies that the Unchecked_Union aspect (see B.3.3) for the type denoted by *first_subtype_*local_name has the value True. J.15.7 Pragmas Interrupt_Handler and Attach_Handler The form of a pragma Interrupt_Handler is as follows: pragma Interrupt_Handler(handler_name); The form of a pragma Attach_Handler is as follows: pragma Attach_Handler(handler_name, expression); Name Resolution Rules For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile. For the Interrupt_Handler pragma, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2). Legality Rules The Attach_Handler and Interrupt_Handler pragmas are only allowed immediately within the protected_definition where the corresponding subprogram is declared. 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. Static Semantics For an implementation that supports Annex C, a pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value True. For an implementation that supports Annex C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value of the given expression [Redundant: as evaluated at object creation time]. J.15.8 Shared variable pragmas Syntax The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and Volatile_Components, and Independent_Components is as follows: pragma Atomic(local_name); pragma Volatile(local_name); pragma Independent(component_local_name); pragma Atomic_Components(array_local_name); pragma Volatile_Components(array_local_name); pragma Independent_Components(local_name); Name Resolution Rules The local_name in an Atomic or Volatile pragma shall resolve to denote either an object_declaration, a non-inherited component_declaration, or a full_type_declaration. The component_local_name in an Independent pragma shall resolve to denote a non-inherited component_declaration. The array_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. The local_name in an Independent_Components pragma shall resolve to denote the declaration of an array or record type or an array object of an anonymous type. Static Semantics These pragmas are representation pragmas (see 13.1). Each of these pragmas specifies that the similarly named aspect (see C.6) of the type, object, or component denoted by its argument is True. Legality Rules The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified. J.15.9 pragma CPU AARM Discussion: This pragma is born obsolescent; it is defined to provide consistency with existing real-time pragmas. Syntax The form of a pragma CPU is as follows: pragma CPU (expression); Name Resolution Rules The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range. Legality Rules A CPU pragma is allowed only immediately within a task_definition, or the declarative_part of a subprogram_body. For a CPU pragma that appears in the declarative_part of a subprogram_body, the expression shall be static. Static Semantics For an implementation that supports Annex D, a pragma CPU specifies the value of the CPU aspect (see D.16). If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma. [Editor's note: J.15.10 is in AI05-0167-1.] J.15.11 Pragmas Priority and Interrupt_Priority Syntax The form of a pragma Priority is as follows: pragma Priority(expression); The form of a pragma Interrupt_Priority is as follows: pragma Interrupt_Priority[(expression)]; Name Resolution Rules The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer. Legality Rules A Priority pragma is allowed only immediately within a task_definition, a protected_definition, or the declarative_part of a subprogram_body. An Interrupt_Priority pragma is allowed only immediately within a task_definition or a protected_definition. For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority. Static Semantics For an implementation that supports Annex D, a pragma Priority specifies the value of the Priority aspect (see D.1) and a pragma Interrupt_Priority specifies the value of the Interrupt_Priority aspect as follows: * If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma; * If the pragma appears in a protected_definition, the expression is associated with the aspect for the protected type or single_protected_declaration that contains the pragma; * If the pragma appears in the declarative part of a subprogram_body, the expression is associated with the aspect for the subprogram that contains the pragma. If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last. J.15.12 pragma Relative_Deadline Syntax The form of a pragma Relative_Deadline is as follows: pragma Relative_Deadline (relative_deadline_expression); Name Resolution Rules The expected type for relative_deadline_expression is Real_Time.Time_Span. Legality Rules A Relative_Deadline pragma is allowed only immediately within a task_definition or the declarative_part of a subprogram_body. Static Semantics For an implementation that supports Annex D, a pragma Relative_Deadline specifies the value of the Relative_Deadline aspect (see D.2.6). If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma. J.15.13 Pragma Asynchronous Syntax The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows: pragma Asynchronous(local_name); Static Semantics For an implementation that supports Annex E, a pragma Asynchronous specifies that 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 may have aspect Asynchronous specified. 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 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 subprogram. See 13.3.1. Size: Size in bits of a subtype or object See 13.3. 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.] !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). The use of aspects as compared to pragmas is strongly preferred for subprograms (as there are no overloading problems to worry about; the target subprogram is obvious). The use of aspects is also preferred for types and objects, as the pragmas can get separated from the declarations and the declarations are (usually) short. There is no clear-cut decision for aspects applying to packages or other entities. Since we want to encourage the use of aspects, we make pragmas that can be replaced by aspects obsolescent, with the exception of pragmas that are primarily used on packages. Following is a list of all Ada pragmas, listed in categories. ---------------- 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. ---------------- Pragmas that could be Boolean operational or representation aspects (subject to other concerns): 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 using the 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 (and AI05-0030-2). 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. --------------------------- During the discussion of this AI, the question of the value of pragma Controlled came up. As far as we can tell, no implementation supports this pragma and no user uses it other than by mistake (believing it does something it does not). Beyond that, the name is confusing (as it uses the same term as finalization). Therefore, we decided to drop this pragma completely (rather than turn it into 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 used to complete a declaration, such as a pragma Import;> @dby @xbullet used to complete a declaration;> !corrigendum 2.8(29/2) @drepl @xcode<@b List(Off); -- @ft<@i> @b Optimize(Off); -- @ft<@i> @b Inline(Set_Mask); -- @ft<@i> @b Import(C, Put_Char, External_Name =@> "putchar"); -- @ft<@i>> @dby @xcode<@b List(Off); -- @ft<@i> @b Optimize(Off); -- @ft<@i> @b Pure(Rational_Numbers); -- @ft<@i> @b Assert(Exists(File_Name), Message =@> "Nonexistent file"); -- @ft<@i>> !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 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 @xcode<@b Worker(Prio : System.Priority; Buf : @b Buffer) @b --@ft<@i< discriminants used to parameterize the task type (see 9.1)>> @b Priority(Prio); --@ft<@i< see D.1>> @b Fill; @b Drain; @b Worker;> @dby @xcode<@b Worker(Prio : System.Priority; Buf : @b Buffer) @b Priority =@> Prio @b --@ft<@i< see D.1>> --@ft<@i< discriminants used to parameterize the task type (see 9.1)>> @b Fill; @b Drain; @b Worker;> !corrigendum 3.9(18.2/2) @drepl @xcode<@b @b T (<@>) @b; @b Parameters (<@>) @b; @b Constructor (Params : @b Parameters) @b T @b; @b Ada.Tags.Generic_Dispatching_Constructor (The_Tag : Tag; Params : @b Parameters) @b T'Class; @b Preelaborate(Generic_Dispatching_Constructor); @b Convention(Intrinsic, Generic_Dispatching_Constructor);> @dby @xcode<@b @b T (<@>) @b; @b Parameters (<@>) @b; @b Constructor (Params : @b Parameters) @b T @b; @b Ada.Tags.Generic_Dispatching_Constructor (The_Tag : Tag; Params : @b Parameters) @b T'Class @b Convention =@> Intrinsic; @b Preelaborate(Generic_Dispatching_Constructor);> !corrigendum 3.11(11) @drepl @xbullet Import applies to the protected type), a check is made that the @fa is already elaborated. This check and the evaluations of any actual parameters of the call are done in an arbitrary order.> @dby @xbullet 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, 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, 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 @s9<27 Implementations are permitted, but not required, to provide garbage collection (see 13.11.3).> @dby @s9<27 Implementations are permitted, but not required, to provide garbage collection.> !corrigendum 6.1(20/2) @drepl A @fa or a @fa requires a completion: a body, a @fa (see 8.5), or a @fa Import (see B.1). A completion is not allowed for an @fa (see 3.9.3) or a @fa (see 6.7). @dby A @fa or a @fa requires a completion: unless the Import aspect (see B.1) is True for the declaration; the completion shall be a body or a @fa (see 8.5). A completion is not allowed for an @fa (see 3.9.3), a @fa (see 6.7), or an @fa (see 6.8). !corrigendum 6.3.1(3) @drepl @xbullet. A @fa Convention, Import, or Export may be used to override the default calling convention (see B.1).> @dby @xbullet. 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@fa in a @fa Convention, Import, or Export. @dby Of these four conventions, only Ada and Intrinsic are allowed as a @I@fa in the specification of a Convention aspect. !corrigendum 6.3.2(2) @ddel The form of a @fa Inline, which is a program unit pragma (see 10.1.5), is as follows: !corrigendum 6.3.2(3) @ddel @xcode<@ft<@b Inline(@fa {, @fa});>> !corrigendum 6.3.2(4) @ddel The @fa shall apply to one or more callable entities or generic subprograms. !corrigendum 6.3.2(5) @drepl If a @fa Inline applies to a callable entity, this indicates that inline expansion is desired for all calls to that entity. If a @fa Inline applies to a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram. @dby For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified: @xhang<@xtermThe type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.> @xindent shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.> !corrigendum 6.3.2(6) @drepl For each call, an implementation is free to follow or to ignore the recommendation expressed by the @fa. @dby For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect. !corrigendum 6.3.2(6.1/2) @ddel An implementation may allow a @fa Inline that has an argument which is a @fa denoting a @fa of the same @fa. !corrigendum 6.3.2(7) @ddel @s9 in a @fa Inline can denote more than one entity in the case of overloading. Such a @fa applies to all of the denoted entities.> !corrigendum 6.5.1(0) @drepl Pragma No_Return @dby Non-returning Procedures !corrigendum 6.5.1(1/2) @drepl A @fa No_Return indicates that a procedure cannot return normally; it may propagate an exception or loop forever. @dby Specifying aspect No_Return to have the value True indicates that a procedure cannot return normally; it may propagate an exception or loop forever. !corrigendum 6.5.1(2/2) @ddel The form of a @fa No_Return, which is a representation pragma (see 13.1), is as follows: !corrigendum 6.5.1(3/2) @drepl @xcode<@ft<@b No_Return(@i@fa{, @i@fa});>> @dby @s8<@i> For a procedure or generic procedure, the following language-defined representation aspect may be specified: @xhang<@xterm The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be @i.> @xindent shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.> If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances. !corrigendum 6.5.1(4/2) @drepl Each @i@fa shall denote one or more procedures or generic procedures; the denoted entities are @i. The @i@fa shall not denote a null procedure nor an instance of a generic unit. @dby Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit. !corrigendum 6.5.1(8/2) @ddel If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances. !corrigendum 6.5.1(10/2) @drepl @xcode<@b Fail(Msg : String); --@ft<@i< raises Fatal_Error exception>> @b No_Return(Fail); --@ft<@i< Inform compiler and reader that procedure never returns normally>>> @dby @xcode<@b Fail(Msg : String) --@ft<@i< raises Fatal_Error exception>> @b No_Return; --@ft<@i< Inform compiler and reader that procedure never returns normally>>> !corrigendum 7.4(2) @drepl A @i is an @fa with the reserved word @b but no initialization expression. The constant declared by a deferred constant declaration is called a @i. A deferred constant declaration requires a completion, which shall be a full constant declaration (called the @i of the deferred constant), or a @fa Import (see Annex B). @dby A @i is an @fa with the reserved word @b but no initialization expression. The constant declared by a deferred constant declaration is called a @i. A deferred constant declaration requires a completion, which shall be a full constant declaration (called the @i 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 Import need not appear in the visible part of a @fa, 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, and has no full constant declaration. !corrigendum 7.4(14) @drepl @xcode String(1..8); @b Import(Assembler, CPU_Identifier, Link_Name => "CPU_ID"); --@ft<@i< see B.1>>> @dby @xcode String(1..8) @b Import =@> True, Convention =@> Assembler, Link_Name =@> "CPU_ID"; --@ft<@i< see B.1>>> !corrigendum 9.10(1) !comment This contains the AI-0009-1 and AI-0201-1 changes as well. @drepl If two different objects, including nonoverlapping parts of the same object, are @i, they can be manipulated concurrently by two different tasks without synchronization. Normally, any two nonoverlapping objects are independently addressable. However, if packing, record layout, or Component_Size is specified for a given composite object, then it is implementation defined whether or not two nonoverlapping parts of that composite object are independently addressable. @dby If two different objects, including nonoverlapping parts of the same object, are @i, they can be manipulated concurrently by two different tasks without synchronization. Any two nonoverlapping objects are independently addressable if either object is specified as independently addressable (see C.6). Otherwise, two nonoverlapping objects are independently addressable except when they are both parts of a composite object for which a non-confirming representation item is used to specify 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 Atomic or Atomic_Components may also be used to ensure that certain reads and updates are sequential @emdash see C.6. @dby Aspect Atomic or aspect Atomic_Components may also be specified to ensure that certain reads and updates are sequential @emdash see C.6. !corrigendum 10.1.4(7/2) @drepl When a compilation unit that declares or renames a library unit is added to the environment, the implementation may remove from the environment any preexisting @fa or @fa with the same full expanded name. When a compilation unit that is a subunit or the body of a library unit is added to the environment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a compilation unit that contains a @fa is added to the environment, the implementation may remove any preexisting @fa or @fa with the same full expanded name as the @fa. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically upon the given one. If the given compilation unit contains the body of a subprogram to which a @fa Inline applies, the implementation may also remove any compilation unit containing a call to that subprogram. @dby When a compilation unit that declares or renames a library unit is added to the environment, the implementation may remove from the environment any preexisting @fa or @fa with the same full expanded name. When a compilation unit that is a subunit or the body of a library unit is added to the environment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a compilation unit that contains a @fa is added to the environment, the implementation may remove any preexisting @fa or @fa with the same full expanded name as the @fa. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically upon the given one. If the given compilation unit contains the body of a subprogram for which aspect Inline is True, the implementation may also remove any compilation unit containing a call to that subprogram. !corrigendum 10.2(15) @drepl @xbullet to which a @fa Elaborate_Body applies is immediately followed by its @fa, if included.> @dby @xbullet for which aspect Elaborate_Body is True (including when a @fa Elaborate_Body applies) is immediately followed by its @fa, if included.> !corrigendum 10.2.1(25) @drepl If a @fa Elaborate_Body applies to a declaration, then the declaration requires a completion (a body). @dby If the aspect Elaborate_Body is True for a declaration (including when @fa Elaborate_Body applies), then the declaration requires a completion (a body). !corrigendum 10.2.1(26) @drepl A @fa Elaborate specifies that the body of the named library unit is elaborated before the current @fa. A @fa Elaborate_All specifies that each @fa that is needed by the named library unit declaration is elaborated before the current @fa. A @fa Elaborate_Body specifies that the body of the library unit is elaborated immediately after its declaration. @dby A @fa Elaborate specifies that the body of the named library unit is elaborated before the current @fa. A @fa Elaborate_All specifies that each @fa that is needed by the named library unit declaration is elaborated before the current @fa. A @fa Elaborate_Body sets the Elaborate_Body representation aspect of the 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. !corrigendum 11.4.1(4/2) @drepl @xcode< @b Raise_Exception(E : @b Exception_Id; Message : @b String := ""); @b No_Return(Raise_Exception); @b Exception_Message(X : Exception_Occurrence) @b String; @b Reraise_Occurrence(X : @b Exception_Occurrence);> @dby @xcode< @b Raise_Exception(E : @b Exception_Id; Message : @b String := "") @b No_Return; @b Exception_Message(X : Exception_Occurrence) @b String; @b Reraise_Occurrence(X : @b Exception_Occurrence);> !corrigendum 11.5(7.2/2) @drepl If a checking pragma applies to a generic instantiation, then the checking pragma also applies to the instance. If a checking pragma applies to a call to a subprogram that has a @fa Inline applied to it, then the checking pragma also applies to the inlined subprogram body. @dby If a checking pragma applies to a generic instantiation, then the checking pragma also applies to the instance. If a checking pragma applies to a call to a subprogram for which aspect Inline is True, then the checking pragma also applies to the inlined subprogram body. !corrigendum 11.6(6) @drepl If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding @fa (or the termination of the task, if none), the external interactions that have occurred need reflect only that the exception was raised somewhere within the execution of the @fa with the handler (or the @fa), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or @i subprogram that does not dynamically enclose the execution of the construct whose check failed. An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and has no Inline pragma applied to it. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be 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. @dby If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding @fa (or the termination of the task, if none), the external interactions that have occurred need reflect only that the exception was raised somewhere within the execution of the @fa with the handler (or the @fa), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or @i subprogram that does not dynamically enclose the execution of the construct whose check failed. An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and for which the Inline aspect is False. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be 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 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 !corrigendum 13.2(0) @drepl Pragma Pack @dby Packed Types !corrigendum 13.2(1) @drepl A @fa Pack specifies that storage minimization should be the main criterion when selecting the representation of a composite type. @dby The Pack aspect having the value True specifies that storage minimization should be the main criterion when selecting the representation of a composite type. !corrigendum 13.2(2) @ddel The form of a @fa Pack is as follows: !corrigendum 13.2(3) @ddel @xcode<@ft<@b Pack(@i@fa);>> !corrigendum 13.2(4) @ddel The @i@fa of a @fa Pack shall denote a composite subtype. !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 @s9<5 A @fa, Component_Size clause, or a @fa Pack can override a specified Alignment.> @dby @s9<5 A @fa, Component_Size clause, or specifying the Pack aspect to True can override a specified Alignment.> !corrigendum 13.3(58) @drepl @s9<7 A @fa or Component_Size clause can override a specified Size. A @fa Pack cannot.> @dby @s9<7 A @fa or Component_Size clause can override a specified Size. Aspect Pack cannot.> !comment %% 13.3(60), 13.3(61), 13.3(62), 13.3(63), and 13.3(64) need changes here. !corrigendum 13.3(65) @drepl @s8<@i> The @fa of a @fa Storage_Size is expected to be of any integer type. @dby @s8<@i> For a task type (including the anonymous type of a @fa), the following language-defined representation aspect may be specified: @xhang<@xTerm The aspect Storage_Size is an @fa, which shall be of any integer type.> @s8<@i> The Storage_Size aspect shall not be specified for a task interface type. !corrigendum 13.3(66) @drepl A @fa Storage_Size is elaborated when an object of the type defined by the immediately enclosing @fa is created. For the elaboration of a @fa Storage_Size, the @fa is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the @fa. @dby When a task object is created, the @fa (if any) associated with the Storage_Size aspect of its type is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the @fa. !corrigendum 13.3(73) @drepl @xbullet @dby @xbullet !corrigendum 13.3.1(0) @dinsc Force a conflict; the real text is found in the conflict file. !corrigendum 13.6(1) @drepl A @fa (see 4.6) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types need to be declared with matching component subtypes, and convertible index types. If one type has packing specified and the other does not, then explicit conversion can be used to pack or unpack an array. @dby A @fa (see 4.6) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types need to be declared with matching component subtypes, and convertible index types. If one type has Pack specified 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 @xcode Set_Mask; @b Inline(Set_Mask);> @dby @xcode Set_Mask @b Inline;> !comment %% 13.9(3) needs change here. !comment %% 13.11.2(3) needs change here. !corrigendum 13.11.3(1) @ddel Pragma Controlled is used to prevent any automatic reclamation of storage (garbage collection) for the objects created by @fas of a given access type. !corrigendum 13.11.3(2) @ddel @xindent !corrigendum 13.11.3(3) @ddel @xcode<@ft<@b Controlled(@i@fa)>> !corrigendum 13.11.3(4) @ddel The @i@fa of a @fa Controlled shall denote a non-derived access subtype. !corrigendum 13.11.3(5) @ddel A @fa Controlled is a representation pragma that specifies the controlled aspect of representation. !corrigendum 13.11.3(6) @ddel @i is a process that automatically reclaims storage, or moves objects to a different address, while the objects still exist. !corrigendum 13.11.3(7) @ddel If a @fa Controlled is specified for an access type with a standard storage pool, then garbage collection is not performed for objects in that pool. !corrigendum 13.11.3(8) @ddel An implementation need not support garbage collection, in which case, a pragma Controlled has no effect. !corrigendum 13.12.1(4/2) @drepl @xhang<@xterm There is no use of language features defined in Annex J. It is implementation-defined if uses of the renamings of J.1 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.> @dby @xhang<@xterm There is no use of language features defined in Annex J. It is implementation defined whether uses of the renamings of J.1 and of the @fas of J.15 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.> !comment %% A.1(37), A.1(42), and A.1(42.1/2) need changes here. !corrigendum B.1(0) @drepl Interfacing Pragmas @dby Interfacing Aspects !corrigendum B.1(1) @drepl A @fa Import is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, a @fa Export is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The @fas Import and Export are intended primarily for objects and subprograms, although implementations are allowed to support other entities. @dby An @i aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention. Specifying aspect Import to have the value True is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, specifying aspect Export to have the value True is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The Import and Export aspects are intended primarily for objects and subprograms, although implementations are allowed to support other entities. The Link_Name and External_Name aspects are used to specify the link name and external name, respectively, to be used to identify imported or exported entities in the external environment. !corrigendum B.1(2) @drepl A @fa Convention is used to specify that an Ada entity should use the conventions of another language. It is intended primarily for types and "callback" subprograms. For example, "@b Convention(Fortran, Matrix);" implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order. @dby The Convention aspect is used to indicate that an Ada entity should use the conventions of another language. It is intended primarily for types and "callback" subprograms. For example, "@b Convention =@> Fortran" on the declaration of an array type Matrix implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order. !comment %% B.1(4), B.1(5), B.1(6), B.1(7) and B.1(9.1/1) need changes here. !corrigendum B.1(10) @drepl The expected type for a @i@fa in an interfacing pragma or in pragma Linker_Options is String. @dby The Import and Export aspects are of type Boolean. The Link_Name and External_Name aspects are of type String. The expected type for the @i@fa in pragma Linker_Options is String. !comment %% B.1(11), B.1(14), B.1(21), and B.1(22) need changes here. !corrigendum B.1(23) @drepl An entity specified as the Entity argument to a @fa Import (or @fa Export) is said to be @i (respectively, @i). @dby An entity with a True Import aspect (or Export aspect) is said to be @i (respectively, @i). An entity shall not be both imported and exported. !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@fas of a @fa Import or Export, and the @i@fa of a @fa Linker_Options, shall be static. @dby The @fa (if any) used to directly specify an Import, Export, External_Name, or Link_Name aspect shall be a static expression. The @i@fa of a @fa 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 @fas are representation pragmas that specify the convention aspect of representation. In addition, Import and Export @fas 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. 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 Import specifies that the entity is defined externally (that is, outside the Ada program).> @dby @xbullet !corrigendum B.1(32) @drepl @xbullet Export specifies that the entity is used externally.> @dby @xbullet !corrigendum B.1(33) @drepl @xbullet Import or Export optionally specifies an entity's external name, link name, or both.> @dby @xbullet !corrigendum B.1(38) @drepl Notwithstanding what this International Standard says elsewhere, the elaboration of a declaration denoted by the @fa of a @fa 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 for 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 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@fa C_Pass_By_Copy shall only be applied to a type. @dby The Convention aspect with @i@fa 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@fa for a C-eligible type (see B.1). An implementation shall support pragma Convention with a C_Pass_By_Copy @i@fa for a C_Pass_By_Copy-eligible type. @dby An implementation shall support specifying aspect Convention with a C @i@fa for a C-eligible type (see B.1). An implementation shall support specifying aspect Convention with a C_Pass_By_Copy @i@fa 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@fa C in the following cases: @xbullet @xbullet @xbullet !corrigendum B.3(78) @drepl @xcode< @ft<@i<-- Note: since the C function's return value is of no interest, the Ada interface is a procedure>> @b Strcpy (Target : @b C.char_array; Source : @b C.char_array);> @dby @xcode< @ft<@i<-- Note: since the C function's return value is of no interest, the Ada interface is a procedure>> @b Strcpy (Target : @b C.char_array; Source : @b C.char_array) @b Import =@> True, Convention =@> C, External_Name =@> "strcpy";> !corrigendum B.3(79) @ddel @xcode< @b 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 @fc<@b 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 Pragma Unchecked_Union @dby Unchecked Union Types !comment %% B.3.3(1/2), B.3.3(2/2), B.3.3(3/2), B.3.3(4/2), B.3.3(5/2), and B.3.3(6/2) need changes here. !corrigendum B.3.3(29/2) @ddel An implementation may require that @fa Controlled be specified for the type of an access subcomponent of an unchecked union type. !corrigendum B.3.3(31/2) @drepl @xcode<@s9< @b T (Flag : Boolean := False) @b @b @b Flag @b @b False =@> F1 : Float := 0.0; @b True =@> F2 : Integer := 0; @b; @b; @b Unchecked_Union (T);>> @dby @xcode<@s9< @b T (Flag : Boolean := False) @b @b @b Flag @b @b False =@> F1 : Float := 0.0; @b True =@> F2 : Integer := 0; @b; @b @b 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.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 support for interfacing aspects (see Annex B) should include 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) @drepl The Attach_Handler pragma is only allowed immediately within the @fa where the corresponding subprogram is declared. The corresponding @fa or @fa shall be a library-level declaration. @dby If either the Attach_Hander or Interrupt_Handler aspect are specifed for a protected procedure, the corresponding @fa or @fa 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), this rule also applies in the private part of an instance of a generic unit. !corrigendum C.3.1(9) @drepl If the pragma Interrupt_Handler appears in a @fa, then the corresponding procedure can be attached dynamically, as a handler, to interrupts (see C.3.2). Such procedures are allowed to be attached to multiple interrupts. @dby If the Interrupt_Handler aspect of a protected procedure is True, then the procedure may be attached dynamically, as a handler, to interrupts (see C.3.2). Such procedures are allowed to be attached to multiple interrupts. !corrigendum C.3.1(10) @drepl The @fa in the Attach_Handler pragma as evaluated at object creation time specifies an interrupt. As part of the initialization of that object, if the Attach_Handler pragma is specified, the @i 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. @dby The @fa specified for the Attach_Handler aspect of a protected procedure @i

is evaluated as part of the creation of the protected object that contains @i

. The value of the @fa identifies an interrupt. As part of the initialization of that object, @i

(the @i procedure) is attached to the identified 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. !corrigendum C.3.1(11/2) @drepl If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which that either an Attach_Handler or Interrupt_Handler pragma applies to one of its procedures, a check is made that the ceiling priority defined in the @fa is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. @dby If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object that contains a protected procedure for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True, a check is made that the initial ceiling priority of the object is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. !corrigendum C.3.1(12/1) @drepl 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 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. @dby 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 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. !corrigendum C.3.1(14.1/1) @drepl If the handlers for a given interrupt attached via pragma 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 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. @dby If the handlers for a given interrupt attached via 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 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. !corrigendum C.3.1(17) @drepl When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding @fa and @fa. @dby When the aspects Attach_Handler or Interrupt_Handler are specified for a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding @fa and @fa. !corrigendum C.3.1(19) @drepl Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers. @dby Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler aspects are allowed to be used for other, implementation defined, forms of interrupt handlers. !corrigendum C.3.1(22) @drepl @s9<4 The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)> @dby @s9<4 The Attach_Handler aspect may provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)> !corrigendum C.3.2(17) @drepl The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any existing treatment (including a user handler) in effect for that interrupt. If New_Handler is @b, the default treatment is restored. If New_Handler designates a protected procedure to which the pragma Interrupt_Handler does not apply, Program_Error is raised. In this case, the operation does not modify the existing interrupt treatment. @dby The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any existing treatment (including a user handler) in effect for that interrupt. If New_Handler is @b, the default treatment is restored. If New_Handler designates a protected procedure for which the aspect Interrupt_Handler is False, Program_Error is raised. In this case, the operation does not modify the existing interrupt treatment. !corrigendum C.3.2(21) @drepl If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt is made to detach a handler that was attached statically (using the pragma Attach_Handler), the handler is not detached and Program_Error is raised. @dby If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt is made to detach a handler that was attached statically (using the aspect Attach_Handler), the handler is not detached and Program_Error is raised. !corrigendum C.3.2(24) @drepl If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains either the Attach_Handler or Interrupt_Handler pragmas, but not the Interrupt_Priority pragma. This default need not be the same for all interrupts. @dby If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains a protected procedure that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. This default need not be the same for all interrupts. !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 Atomic(@fa);> !corrigendum C.6(4) @ddel @xindent<@b Volatile(@fa);> !corrigendum C.6(5) @ddel @xindent<@b Atomic_Components(@i@fa);> !corrigendum C.6(6) @ddel @xindent<@b Volatile_Components(@i@fa);> !comment %% C.6(7/2) and C.6(8) need changes here. !corrigendum C.6(9) @ddel The @fa in an Atomic or Volatile pragma shall resolve to denote either an @fa, a non-inherited @fa, or a @fa. The @i@fa 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, the declaration shall be that of an array or record type. It is illegal to specify either of the aspects Atomic or Atomic_Components to have the value True for an object or type if the implementation cannot support the indivisible reads and updates 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, Volatile_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. !comment %% D.1(2), D.1(3), D.1(4), D.1(5), D.1(6), and D.1(7) need changes here. !corrigendum D.1(8) @drepl For a Priority pragma that appears in the @fa of a @fa, the @fa shall be static, and its value shall be in the range of System.Priority. @dby If the Priority aspect is specified for a subprogram, the @fa shall be static, and its value shall be in the range of System.Priority. At most one of the Priority and Interrupt_Priority aspects may be specified for a given entity. Neither of the Priority or Interrupt_Priority aspects shall be specified for a synchronized interface type. !corrigendum D.1(13) @ddel The priority specified by a Priority or Interrupt_Priority pragma is the value of the @fa in the pragma, if any. If there is no @fa in an Interrupt_Priority pragma, the priority value is Interrupt_Priority'Last. !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) @drepl A Relative_Deadline pragma has no effect if it occurs in the @fa of the @fa of a subprogram other than the main subprogram. @dby The Relative_Deadline aspect has no effect if it is specified for a subprogram other than the main subprogram. !corrigendum D.2.6(13/2) @drepl The initial absolute deadline of a task containing pragma Relative_Deadline is the value of Real_Time.Clock + @i@fa, 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 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. @dby The initial absolute deadline of a task for which aspect Relative_Deadline is specified is the value of Real_Time.Clock + the @fa that is the value of the aspect, where this entire expression, including the call of Real_Time.Clock, is evaluated between task creation and the start of its activation. If the aspect Relative_Deadline is not specified, 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, using the value of the Relative_Deadline aspect of the main subprogram (if any). !corrigendum D.3(6.1/2) @drepl The @fa of a Priority or Interrupt_Priority pragma (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 a protected object, the initial priority is specified by the locking policy. @dby The @fa 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 aspect is specified for a protected object, the initial priority is specified by the locking policy. !corrigendum D.3(8/2) @drepl @xbullet, which is determined by either a Priority or Interrupt_Priority pragma as defined in D.1, or by assignment to the Priority attribute as described in D.5.2. The ceiling priority of a protected object (or ceiling, for short) is an upper bound on the active priority a task can have when it calls protected operations of that protected object.> @dby @xbullet, which is determined by either a Priority or Interrupt_Priority aspect as defined in D.1, or by assignment to the Priority attribute as described in D.5.2. The ceiling priority of a protected object (or ceiling, for short) is an upper bound on the active priority a task can have when it calls protected operations of that protected object.> !corrigendum D.3(10/2) @drepl @xbullet 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.> @dby @xbullet !corrigendum D.3(11/2) @drepl @xbullet, then the initial priority of the corresponding protected object is System.Priority'Last.> @dby @xbullet !corrigendum D.5.2(6/2) @drepl If the locking policy Ceiling_Locking is in effect, then for a protected object @i

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 @i

'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

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 @i

'Priority is in the range System.Interrupt_Priority. If the check fails, Program_Error is raised. !corrigendum D.13(5/2) @drepl Force a conflict; @dby the real text is found in the conflict file. !corrigendum D.16(0) @dinsc Force a conflict; the real text is found in the conflict file. !corrigendum E.2.3(13/1) @drepl @xbullet @dby @xbullet !corrigendum E.2.3(16) @drepl If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call interface. @dby A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the library unit to which the pragma 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. !corrigendum E.2.3(19/1) @drepl If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the unit are defined to be local and shall not go through the PCS. @dby If aspect All_Calls_Remote is True for a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the unit are defined to be local and shall not go through the PCS. !corrigendum E.4.1(0) @drepl Pragma Asynchronous @dby Asynchronous Remote Subprograms !corrigendum E.4.1(1) @drepl This subclause introduces the pragma Asynchronous which allows a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body. @dby This subclause introduces the aspect Asynchronous which can be specified to allow a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body. !comment %% E.4.1(2), E.4.1(3), E.4.1(4), E.4.1(5), and E.4.1(6) need to be deleted here. !corrigendum E.4.1(7) @ddel @xbullet !corrigendum E.4.1(8) @drepl A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the type-related @i aspect of the type. @dby For a remote procedure, the following language-defined representation aspect may be specified: @xhang<@xterm The type of aspect Asynchronous is Boolean. If directly specified, the @fa 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: @xhang<@xterm The type of aspect Asynchronous is Boolean. If directly specified, the @fa shall be a static expression. If not specified (including by inheritance), the aspect is False.> @s8<@i> If aspect Asynchronous is specified for a remote procedure, the formal parameters of the procedure shall all be of mode @b. 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 @i. !corrigendum E.4.1(9) @drepl A remote call is @i if it is a call to a procedure, or a call through a value of an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma Asynchronous 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 @b. @dby A remote call is @i if it is a call to a procedure, or a call through a value of an access-to-procedure type, for which aspect Asynchronous is True. In addition, if aspect Asynchronous is True for 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 @b. !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 @i@fa 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 @i@fa of COBOL (respectively, C) for 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 @b Dividend_Type @b <@> @b <@>; @b Divisor_Type @b <@> @b <@>; @b Quotient_Type @b <@> @b <@>; @b Remainder_Type @b <@> @b <@>; @b Divide (Dividend : @b Dividend_Type; Divisor : @b Divisor_Type; Quotient : @b Quotient_Type; Remainder : @b Remainder_Type); @b Convention(Intrinsic, Divide);> @dby @xcode< @b @b Dividend_Type @b <@> @b <@>; @b Divisor_Type @b <@> @b <@>; @b Quotient_Type @b <@> @b <@>; @b Remainder_Type @b <@> @b <@>; @b Divide (Dividend : @b Dividend_Type; Divisor : @b Divisor_Type; Quotient : @b Quotient_Type; Remainder : @b Remainder_Type) @b Convention =@> Intrinsic;> !corrigendum G(7) @drepl If Fortran (respectively, C) is widely supported in the target environment, implementations supporting the Numerics Annex should provide the child package Interfaces.Fortran (respectively, Interfaces.C) specified in Annex B and should support a @i@fa 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 Numerics Annex should provide the child package Interfaces.Fortran (respectively, Interfaces.C) specified in Annex B and should support a @i@fa of Fortran (respectively, C) for the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs written in that language. !corrigendum J.9(3/2) @drepl Storage_Size may be specified for a task first subtype that is not an interface via an @fa. @dby Storage_Size may be specified for a task first subtype that is not an interface via an @fa. When the attribute is specified, the Storage_Size aspect is specified to be the value of the given @fa. !corrigendum J.15(0) @dinsc Pragmas can be used as an alternative to aspect_specifications to specify certain aspects. !corrigendum J.15.1(0) @dinsc @s8<@i> The form of a @fa Inline, which is a program unit pragma (see 10.1.5), is as follows: @xcode<@ft<@b Inline (@fa{, @fa});>> @s8<@i> The @fa shall apply to one or more callable entities or generic subprograms. @s8<@i> @fa Inline specifies that the Inline aspect (see 6.3.2) for each entity denoted by each @fa given in the @fa has the value True. @s8<@i> An implementation may allow a @fa Inline that has an argument which is a @fa denoting a @fa of the same @fa. @s9 Inline may denote more than one entity in the case of overloading. Such a @fa applies to all of the denoted entities.> !corrigendum J.15.2(0) @dinsc @s8<@i> The form of a @fa No_Return, which is a representation pragma (see 13.1), is as follows: @xcode<@ft<@b No_Return (@i@fa{, @i@fa});>> @s8<@i> Each @i@fa shall denote one or more procedures or generic procedures. The @i@fa shall not denote a null procedure nor an instance of a generic unit. @s8<@i> @fa No_Return specifies that the No_Return aspect (see 6.5.1) for each procedure denoted by each @fa given in the @fa has the value True. !corrigendum J.15.3(0) @dinsc @s8<@i> The form of a @fa Pack, which is a representation pragma (see 13.1), is as follows: @xcode<@ft<@b Pack (@i@fa);>> @s8<@i> The @i@fa of a @fa Pack shall denote a composite subtype. @s8<@i> @fa Pack specifies that the Pack aspect (see 13.2) for the type denoted by @i@fa has the value True. !corrigendum J.15.4(0) @dinsc @s8<@i> The form of a @fa Storage_Size is as follows: @xcode<@ft<@b Storage_Size (@fa);>> A @fa Storage_Size is allowed only immediately within a @fa. @s8<@i> The @fa of a @fa Storage_Size is expected to be of any integer type. @s8<@i> The @fa Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined by the immediately enclosing @fa to the value of the @fa of the @fa. !corrigendum J.15.5(0) @dinsc @s8<@i> An @i is a representation pragma that is one of the @fas Import, Export, or Convention. Their forms are as follows: @xcode<@ft<@b Import ( [Convention =@>] @i@fa, [Entity =@>] @fa [, [External_Name =@>] @i@fa] [, [Link_Name =@>] @i@fa]);>> @xcode<@ft<@b Export ( [Convention =@>] @i@fa, [Entity =@>] @fa [, [External_Name =@>] @i@fa] [, [Link_Name =@>] @i@fa]);>> @xcode<@ft<@b Convention ([Convention =@>] @i@fa,[Entity =@>] @fa);>> For pragmas Import and Export, the argument for Link_Name shall not be given without the @i@fa unless the argument for External_Name is given. @s8<@i> The expected type for a @i@fa and a @i@fa in an interfacing pragma is String. @s8<@i> The @i@fa of an interfacing pragma shall be the name of a convention (see B.1). A @fa Import shall be the completion of a declaration. Notwithstanding any rule to the contrary, a @fa 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 Import, then it shall appear in the same @fa, @fa, @fa, or @fa as the declaration. For a library unit, it shall appear in the same @fa, before any subsequent @fas other than @fas. If the @fa denotes more than one entity, then the @fa Import is the completion of all of them. The @i@fa and @i@fa of a @fa Import or Export shall be static. The @fa of each of these pragmas shall denote a declaration that may have the similarly named aspect specified. @s8<@i> An interfacing pragma specifies various aspects of the entity denoted by the @fa as follows: @xbullet@fa.> @xbullet Import specifies that the Import aspect (see B.1) is True.> @xbullet Export specifies that the Export aspect (see B.1) is True.> @xbullet Import and Export, if an external name is given in the pragma, the External_Name aspect (see B.1) is specified to be @i@fa. If a link name is given in the pragma, the Link_Name aspect (see B.1) is specified to be the @i@fa.> !corrigendum J.15.6(0) @dinsc @s8<@i> The form of a @fa Unchecked_Union, which is a representation pragma (see 13.1), is as follows: @xcode<@ft<@b Unchecked_Union (@i@fa);>> @s8<@i> The @i@fa of a @fa Unchecked_Union shall denote an unconstrained discriminated record subtype having a @fa. @s8<@i> A @fa Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3) for the type denoted by @i@fa has the value True. !corrigendum J.15.7(0) @dinsc The form of a @fa Interrupt_Handler is as follows: @xindent<@b Interrupt_Handler (@i@fa);> The form of a @fa Attach_Handler is as follows: @xcode<@ft<@b Attach_Handler (@i@fa, @fa);>> @s8<@i> For the Interrupt_Handler and Attach_Handler pragmas, the @i@fa shall resolve to denote a protected procedure with a parameterless profile. For the Attach_Handler pragma, the expected type for the @fa is Interrupts.Interrupt_Id (see C.3.2). @s8<@i> The Attach_Handler and Interrupt_Handler pragmas are only allowed immediately within the @fa where the corresponding subprogram is declared. The corresponding @fa or @fa 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. @s8<@i> For an implementation that supports Annex C, a pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see C.3.1) for the protected procedure @i@fa to have the value True. For an implementation that supports Annex C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for the protected procedure @i@fa to have the value of the given @fa as evaluated at object creation time. !corrigendum J.15.8 @dinsc @s8<@i> The form for @fas Atomic, Volatile, Independent, Atomic_Components, and Volatile_Components, and Independent_Components is as follows: @xcode<@ft<@b Atomic (@fa);>> @xcode<@ft<@b Volatile (@fa);>> @xcode<@ft<@b Atomic (@i@fa);>> @xcode<@ft<@b Atomic_Components (@i@fa);>> @xcode<@ft<@b Volatile_Components (@i@fa);>> @xcode<@ft<@b Independent_Components (@fa);>> @s8<@i> The @fa in an Atomic or Volatile pragma shall resolve to denote either an @fa, a non-inherited @fa, or a @fa. The @i@fa in an Independent pragma shall resolve to denote a non-inherited @fa. The @i@fa 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. The @fa in an Independent_Components pragma shall resolve to denote the declaration of an array or record type or an array object of an anonymous type. @s8<@i> These @fas are representation pragmas (see 13.1). Each of these @fas specifies that the similarly named aspect (see C.6) of the type, object, or component denoted by its argument is True. @s8<@i> The @fa of each of these @fas shall denote a declaration that may have the similarly named aspect specified. !corrigendum J.15.9 @dinsc @s8<@i> The form of a @fa CPU is as follows: @xcode<@ft<@b CPU (@fa);>> @s8<@i> The expected type for the @fa of a @fa CPU is System.Multiprocessors.CPU_Range. @s8<@i> A CPU pragma is allowed only immediately within a @fa, or the @fa of a @fa. For a CPU pragma that appears in the @fa of a @fa, the @fa shall be static. @s8<@i> For an implementation that supports Annex D, a @fa CPU specifies the value of the CPU aspect (see D.16). If the @fa appears in a @fa, the @fa is associated with the aspect for the task type or @fa that contains the @fa; otherwise, the @fa is associated with the aspect for the subprogram that contains the @fa. !comment J.15.10 is in AI05-0167-1. !corrigendum J.15.11 @dinsc @s8<@i> The form of a @fa Priority is as follows: @xcode<@ft<@b Priority (@fa);>> The form of a @fa Interrupt_Priority is as follows: @xcode<@ft<@b Interrupt_Priority [(@fa)];>> @s8<@i> The expected type for the @fa in a Priority or Interrupt_Priority pragma is Integer. @s8<@i> A Priority pragma is allowed only immediately within a @fa, a @fa, or the @fa of a @fa. An Interrupt_Priority pragma is allowed only immediately within a @fa or a @fa. For a Priority pragma that appears in the @fa of a @fa, the @fa shall be static, and its value shall be in the range of System.Priority. @s8<@i> For an implementation that supports Annex D, a @fa Priority specifies the value of the Priority aspect (see D.1) and a @fa Interrupt_Priority specifies the value of the Interrupt_Priority aspect as follows: @xbullet appears in a @fa, the @fa is associated with the aspect for the task type or @fa that contains the @fa;> @xbullet appears in a @fa, the @fa is associated with the aspect for the protected type or @fa that contains the @fa;> @xbullet appears in the @fa of a @fa, the @fa is associated with the aspect for the subprogram that contains the @fa.> If there is no @fa in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last. !corrigendum J.15.12 @dinsc @s8<@i> The form of a @fa Relative_Deadline is as follows: @xcode<@ft<@b Relative_Deadline (@i@fa);>> @s8<@i> The expected type for a @i@fa is Real_Time.Time_Span. @s8<@i> A Relative_Deadline pragma is allowed only immediately within a @fa or the @fa of a @fa. @s8<@i> For an implementation that supports Annex D, a @fa Relative_Deadline specifies the value of the Relative_Deadline aspect (see D.2.6). If the @fa appears in a @fa, the @fa is associated with the aspect for the task type or @fa that contains the @fa; otherwise, the @fa is associated with the aspect for the subprogram that contains the @fa. !corrigendum J.15.13 @dinsc @s8<@i> The form of a @fa Asynchronous, which is a representation pragma (see 13.1), is as follows: @xcode<@ft<@b Asynchronous (@fa);>> @s8<@i> For an implementation that supports Annex E, a pragma Asynchronous specifies that the Asynchronous aspect (see E.4.1) for the procedure or type denoted by @fa has the value True. @s8<@i> The @fa 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 ACATS tests would be needed to check that all of these aspects can be specified. !appendix From: Bob Duff Sent: Monday, October 25, 2010 2:44 PM From the Valencia minutes: New Action Items ... Bob Duff ... AI to add wording to explain which non-attribute aspects can be specified via aspect clauses, and the exact semantics for such specification. (See discussion of AI05-0183-1.) Participate in the amendment subcommittee ... ---------------- Tucker would like to make a separate AI to handle changes to individual aspects. But add a general statement about specifiable attributes in this AI. Wording needs to be added to 13.1(9-9.1) to include aspect clauses (to prevent specifying one aspect in multiple ways). Tucker says that he tried to use some common wording in AI-139-2, 4.1.6. This would then be used to create an annex similar to the attribute one. We are electing Bob to do this new AI, using the AI05-0139-2 wording as a model. He will need to A,"fixA," the wording from AI05-0145-2 into this format. [Editor's note: I did this for the wording proposed for AI05-0146-1 and in these minutes for AI05-0153-1]. Randy explained the above privately: > We want the AI which defines which aspects can be specified with the > AI-183 to be separate from AI-183, because it is likely to be large > and it would obscure the more complex wording. OK. I've included some wording below. I think I may be misunderstanding what you want, because it's not all that large. If you have in mind rewriting all the rules for every sort of attribute_definition_clause, then, well... That's NUTS! If this job entails rewriting all of chap 13 (again!) plus a bunch of other stuff, then I think we should back off. It is REALLY not important to allow "Foo with Bar => Baz" when there's already a way to say it. > AI-139-2 defines a couple of aspects in a format that Tucker is > proposing be used for *all* specifiable aspects. You can use that as a > model (or AI-146 or AI-153-1 as I already modified them to use that same > format). OK, and as clarified by Tucker privately, some aspects are also attributes, some are also pragmas, and some are just aspects. > We expect that all specifable attributes will be usable as aspects in > aspect clauses in the same way as they can be used in attribute > clauses (that will reduce the needed wording). But we also need > wording for every pragma that can be used as an aspect: probably Pack, > the ones in C.6, Priority, CPU (which is new),... If CPU is new, we could get rid of the pragma, and just make it an aspect. The whole point of aspect_specifications (25 years too late) is to reduce the proliferation of pragmas, each with its own distinct rules. >... etc. Robert had suggested that Pack => False turn off packing (not >sure if that introduces new problems, it definitely would for Atomic). >You'll need to decide if that makes sense. I'm not sure I like the idea of Pack => False. It seems like a neat feature in isolation, but if it requires hard thinking about Atomic and friends, I'm not sure it's worth the trouble. ---------------- I've no idea where the following wording belongs. I'm still not sure exactly what's wanted, so I'm sending this trial baloon to see if it floats. 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. - 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. - Additional aspects that are neither attributes nor pragmas are defined throughout this International Standard. AARM Discussion: The following representation pragmas may also be specified using an aspect_specification: 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 The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28) End AARM Discussion. (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.) Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3). Remove all wording for representation pragmas that says this pragma specifies so-and-so aspect: 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. 13.11.3(5): 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 union aspect of representation]. C.5(6): No changes needed for Discard_Names. 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 type, it specifies the type-related asynchronous aspect of the type.] Add Unchecked_Union to the index under "representation pragma". **************************************************************** From: Tucker Taft Sent: Monday, October 25, 2010 3:10 PM I am interpreting the "[]" as deletions, rather than indicating as redundant. Also, I notice you eliminated the mention that the asynchronous aspect was "type-related." I think we want to preserve the distinction between type-related and subtype-specific aspects. That may affect the legality of specifying the aspect on a subtype declaration. So we should be careful about deleting phrases that include "type-related" or "subtype-specific" unless they show up elsewhere. **************************************************************** From: Bob Duff Sent: Monday, October 25, 2010 5:51 PM > I am interpreting the "[]" as deletions, rather than indicating as > redundant. Right. I get mixed up between {} and []. I think the convention for AI's is {} for insertions, [] for deletions, and Redundant[] for redundancies. The convention in the AARM is [] for redundancies. The convention in the RM is to have no such noise. Please correct me if I'm wrong. >...Also, I notice you eliminated > the mention that the asynchronous aspect was "type-related." So I guess it should be: E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] The Asynchronous aspect is type-related when applied to a type. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:15 PM > Right. I get mixed up between {} and []. I think the convention for > AI's is {} for insertions, [] for deletions, and Redundant[] for > redundancies. The convention in the AARM is [] for redundancies. The > convention in the RM is to have no such noise. > > Please correct me if I'm wrong. That is exactly right. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:42 PM ... > I've no idea where the following wording belongs. I'm still not sure > exactly what's wanted, so I'm sending this trial baloon to see if it > floats. I think it is pretty close. We also need text to introduce the "aspect annex" (the intent is that we will have an annex similar to the attribute one that shows all of the possible aspects). The actual annex will be automatically created somehow. CPU and Priority don't have local names, but they ought to be specifable as aspects. (At least, we ought to consider that!) I'm not sure that Unchecked_Union makes sense here (it's closer to pragma Convention than to the others on this list). I suspect it would be best with the pragmas to simply list the ones that are included (then we don't need to come up with a blanket rule that isn't really quite what we want). **************************************************************** From: Bob Duff Sent: Saturday, October 30, 2010 1:00 PM More info on AI05-0229-1, Specifiable aspects. I tried to study all the pragmas (from Annex L), and see if they make sense as "aspects". ---------------- To make sense as an aspect, the 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". Tucker said he'd work on that. 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). ---------------- Boolean representation attributes already discussed: 3 pragma Asynchronous(local_name); - See E.4.1. 4 pragma Atomic(local_name); - See C.6. 5 pragma Atomic_Components(array_local_name); - See C.6. 7 pragma Controlled(first_subtype_local_name); - See 13.11.3. 9 pragma Discard_Names[([On => ] local_name)]; - See C.5. 14.1/3 pragma Independent(component_local_name); - See C.6. 14.2/3 pragma Independent_Components(local_name); - See C.6. 24 pragma Pack(first_subtype_local_name); - See 13.2. 38 pragma Volatile(local_name); - See C.6. 39 pragma Volatile_Components(array_local_name); - See C.6. 37.1/2 pragma Unchecked_Union (first_subtype_local_name); - See B.3.3. ---------------- More Boolean aspects: 2 pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3. 12 pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1. 15 pragma Inline(name {, name}); - See 6.3.2. 17 pragma Interrupt_Handler(handler_name); - See C.3.1. 21.1/2 pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1. 25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1. 26 pragma Preelaborate[(library_unit_name)]; - See 10.2.1. 28 pragma Pure[(library_unit_name)]; - See 10.2.1. 30 pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3. 31 pragma Remote_Types[(library_unit_name)]; - See E.2.2. 34 pragma Shared_Passive[(library_unit_name)]; - See E.2.1. ---------------- Non-Boolean aspects: 6 pragma Attach_Handler(handler_name, expression); - See C.3.1. -- Aspect type is Interrupts.Interrupt_ID. 8.1/3 pragma CPU (expression); - See D.16. -- Aspect type is System.Multiprocessors.CPU_Range. And this implicitly applies to outer task/prot. Or PROCEDURE! 18 pragma Interrupt_Priority[(expression)]; - See D.1. -- Aspect type is Integer. Does aspect have a default? 27 pragma Priority(expression); - See D.1. -- Aspect type is Integer. Require static in procedure? 29.1/2 pragma Relative_Deadline (relative_deadline_expression); - See D.2.6. -- Aspect type is Real_Time.Time_Span. 35 pragma Storage_Size(expression); - See 13.3. -- Aspect type is universal_integer? ---------------- "identifiers specific to an aspect": 8 pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name); - See B.1. (except the parameters are backwards) 13.1/2 pragma Implemented(procedure_local_name, implementation_kind); - See 9.5. ---------------- Make no sense as aspects: 2.1/2 pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2. 2.2/2 pragma Assertion_Policy(policy_identifier); - See 11.4.2. 8.2/2 pragma Detect_Blocking; - See H.5. 10 pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1. 11 pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 10.2.1. 13 pragma Export( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. 14 pragma Import( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. 16 pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2. 19 pragma Linker_Options(string_expression); - See B.1. 20 pragma List(identifier); - See 2.8. 21 pragma Locking_Policy(policy_identifier); - See D.3. 22 pragma Normalize_Scalars; - See H.1. 23 pragma Optimize(identifier); - See 2.8. 25 pragma Page; - See 2.8. 25.1/2 pragma Partition_Elaboration_Policy (policy_identifier); - See H.6. 27.1/2 pragma Priority_Specific_Dispatching ( policy_identifier, first_priority_expression, last_priority_expression); - See D.2.2. 27.2/2 pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13. 29 pragma Queuing_Policy(policy_identifier); - See D.4. 32 pragma Restrictions(restriction{, restriction}); - See 13.12. 33 pragma Reviewable; - See H.3.1. 36 pragma Suppress(identifier); - See 11.5. 37 pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2. 37.2/2 pragma Unsuppress(identifier); - See 11.5. ---------------- **************************************************************** From: Robert Dewar Sent: Saturday, October 30, 2010 1:12 PM > More info on AI05-0229-1, Specifiable aspects. > I tried to study all the pragmas (from Annex L), and see if they make > sense as "aspects". > 25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1. > > 26 pragma Preelaborate[(library_unit_name)]; - See 10.2.1. > > 28 pragma Pure[(library_unit_name)]; - See 10.2.1. > > 30 pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3. > > 31 pragma Remote_Types[(library_unit_name)]; - See E.2.2. > > 34 pragma Shared_Passive[(library_unit_name)]; - See E.2.1. The library unit ones make no sense to me, it is obviously inferior to have these at the end of the unit instead of the start as wouldl be forced by use of aspects. Just for reference, the current GNAT list is: > Aspect_Address, > Aspect_Alignment, > Aspect_Bit_Order, > Aspect_Component_Size, > Aspect_Dynamic_Predicate, > Aspect_External_Tag, > Aspect_Input, > Aspect_Invariant, > Aspect_Machine_Radix, > Aspect_Object_Size, -- GNAT > Aspect_Output, > Aspect_Post, > Aspect_Pre, > Aspect_Predicate, -- GNAT > Aspect_Read, > Aspect_Size, > Aspect_Static_Predicate, > Aspect_Storage_Pool, > Aspect_Storage_Size, > Aspect_Stream_Size, > Aspect_Suppress, > Aspect_Unsuppress, > Aspect_Value_Size, -- GNAT > Aspect_Warnings, > Aspect_Write, > > -- Remaining aspects have a static boolean value that turns the aspect > -- on or off. They all correspond to pragmas, and the flag Aspect_Cancel > -- is set on the pragma if the corresponding aspect is False. > > Aspect_Ada_2005, -- GNAT > Aspect_Ada_2012, -- GNAT > Aspect_Atomic, > Aspect_Atomic_Components, > Aspect_Discard_Names, > Aspect_Favor_Top_Level, -- GNAT > Aspect_Inline, > Aspect_Inline_Always, -- GNAT > Aspect_No_Return, > Aspect_Pack, > Aspect_Persistent_BSS, -- GNAT > Aspect_Preelaborable_Initialization, > Aspect_Pure_Function, -- GNAT > Aspect_Shared, -- GNAT (equivalent to Atomic) > Aspect_Suppress_Debug_Info, -- GNAT > Aspect_Unchecked_Union, > Aspect_Universal_Aliasing, -- GNAT > Aspect_Unmodified, -- GNAT > Aspect_Unreferenced, -- GNAT > Aspect_Unreferenced_Objects, -- GNAT > Aspect_Volatile, > Aspect_Volatile_Components); **************************************************************** From: Bob Duff Sent: Saturday, October 30, 2010 6:17 PM > The library unit ones make no sense to me, it is obviously inferior to > have these at the end of the unit instead of the start as wouldl be > forced by use of aspects. I wonder if you implemented the right syntax, as specified by the latest version of AI-183. It's something like package P with Elaborate_Body => True is ... end P; This stuff is a moving target -- we keep changing various aspect names, etc. > Just for reference, the current GNAT list is: I haven't had time to compare your list to mine. All I know is, there seems to be pressure from everyone to make everything under the sun into an "aspect". I've no objection to that when it's easy, but a lot of these pragmas have all kinds of strange warts that require thinking about -- and RM wording -- that I'd like to avoid. My previous e-mail is an attempt to list out all pragmas that are remotely possible as aspects. **************************************************************** From: Robert Dewar Sent: Saturday, October 30, 2010 6:32 PM > I wonder if you implemented the right syntax, as specified by the > latest version of AI-183. It's something like > > package P with Elaborate_Body => True is > ... > end P; No, that's new, but why it is somehow preferable to package P is pragma Elaborate_Body; ... end P; when it is more tokens beats me, well we will eventually get these unimportant ones picked up when we figure what they are. This particular one is annoying since it is a special case (no semicolon after the aspect list). **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 10:07 AM I think it is a good idea to have aspects for library unit pragmas, since it is always nicer to do things with proper syntax than pragmas when the result has significant semantic impact, so I prefer package X with Pure is to package X is pragma Pure; BUT, if we allow a Boolean parameter package X with Pure => True is ... then we need special rules, we can't delay the evaluation of True until X is frozen, so I think for such pragmas we shouldn't delay the evaluation of the expression! Actually, I would suggest that, assuming we keep the boolean expression for the boolean cases, with the possibility of False meaning, forget about the aspect entirely (remove the awkward cancellation semantics for the derived type case), then I think we should evaluate the boolean parameter immediately always. It is just silly to allow type R is array ... with Packed => True; ... True : Boolean := False; and if you are using this in a reasonable way to parametrize whether R should be packed, then it is perfectly reasonable for the boolean case to say that you refer to a previously set configuration, something like type R is array ... with Packed => Pack_If_Space_Optimizing; where Pack_If_Space_Optimizing is some global constant (off topic, I have often thought it would be useful to be able to define such global constants in the configuration pragma file, to avoid the need for a million with's :-)) **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 10:34 AM I think we still want to defer resolution of pragmas that apply to packages. We had proposed the notion of a Package_Invariant at one point. That would almost certainly be an expression that would be boolean, and would involve calling a function declared later inside the package. So I am not sure I see the value nor the need to have different rules for aspects that apply to packages, nor for aspects that happen to be boolean. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 11:03 AM > I think we still want to defer resolution of pragmas that apply to > packages. We had proposed the notion of a Package_Invariant at one > point. That would almost certainly be an expression that would be > boolean, and would involve calling a function declared later inside > the package. So I am not sure I see the value nor the need to have > different rules for aspects that apply to packages, nor for aspects > that happen to be boolean. Well this is a case where the compiler is totally unprepared to deal with the equivalent of a pragma Pure appearing at the end of the package. This would be a major earthquake. We check the status of such things as we analyze the declarations of the package, anything else would be huge extra work for almost NO gain, since for something like Pure, being able to defer whether the package is Pure till the end of the package is pretty absurd. Also, how about package P with Pure => Pure_OK is ... Pure_OK : constant Boolean := False; ... end; Now we have the anomoly that if the package is pure, then the declaration is illegal, and cannot affect the legality of the rest of the package, but if it is not pure, then the declaration is OK, and since it indeed False and the package is not Pure. My suggestion applies ONLY to aspects where we require a static Boolean value (e.g. Pack, Pure etc). Of course it does not apply to any situation where we have a general boolean expression. The cases of static boolean values being required for binary aspects that are on (True) or off (False) are really are quite different. If we allow an expression here at all is a matter of debate, if we allow it, allowing False is a matter of debate. But surely delaying the evaluation in such a case is NOT useful, it allows only stupid useless tests at the expense (if applied to pragmas that normally could not be themselves delayed) of huge extra work in the compiler. **************************************************************** From: John Barnes Sent: Monday, November 1, 2010 11:04 AM I haven't really been following this because of being poorly. But I think pragma Pure is fine as it is; I wouldn't want to write. package Ada with Pure is end Ada; Horrid. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 11:11 AM For me package Ada with Pure => True is end Ada; is better than package Ada is pragma Pure; end Ada; because I don't like pragmas having a big effect on legality like this. Better done with syntax. Note the pragma is still there, so if this is just asthetics on your part (note for me there is a real principle about bad pragmas not just syntax aesthetics), then you can still use the pragma if you want. **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 11:54 AM I now understand your concern about Pure. I don't particularly like having to make an exception for this case, but if we make one, it will need to be clearly defined. We already require static values for many aspects, but deferring most to the freezing point is no hardship, since that is where the rep-clause would have taken affect. So we will need some clear distinction for these particular aspects for which we won't allow deferral. Perhaps what you are suggesting is that although it is no hardship, it is also no great advantage, to permit deferral of Boolean aspects that require a static value. Obviously if you had omitted the "=> True" you wouldn't be deferring the determination, so perhaps we can use that as a distinction. Namely if the aspect is Boolean, and it has to be given statically, then in addition, we say that the static expression is resolved and evaluated at the point of the aspect specification. My one bit of discomfort here is for things such as pragma Pack where we might want to decide it based on something like the 'Size of something else. E.g: type Arr_Of_Elem is array(...) of Elem with Pack => Elem'Size <= System.Storage_Unit/2; This use of 'Size will cause freezing of Elem, so we might like it to be deferred as long as possible. So perhaps we should limit it further to aspects that require a static Boolean value and that apply to packages or generic packages. **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 12:29 PM Coming up with some general rule is not really necessary. We have already allowed particular aspects to have their own rules. So aspects Pure and Preelaborated, and perhaps the other various "categorization" aspects like Remote_Types, should have this rule that they require a static expression which is resolved and evaluated at the point of the aspect specification. This would allow use of constants declared in "with"ed packages, but nothing local in the package. The rule that the resolution would be the same if it were deferred to after the end of the package would still seem to be useful to avoid confusion. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:38 PM I disagree in this case, simply not worth the effort and would require a lot of extra mechanism. Why not just decide that the whole business of delayed resolution and checking it is plain silly for these static boolean predicates, the only arguments that make sense are True (9x% of the cases) Some boolean static exptression depending on previously declared stuff (very small % of remaining cases). I really think that worrying about having type x is array (0 .. 31) of Boolean with Pack => True; ... True : Boolean := False; being required to generate a message is not worth any discussion, let alone implementation effort. It's so much cleaner to say that these aspects are analyzed and evaluated at the time of the aspect appearing. If it evaluates to True, the aspect is active, if it is False, then the aspect is entirely ignored, end of story. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:41 PM > Perhaps what you are suggesting > is that although it is no hardship, it is also no great advantage, to > permit deferral of Boolean aspects that require a static value. > Obviously if you had omitted the "=> True" > you wouldn't be deferring the determination, so perhaps we can use > that as a distinction. > Namely if the aspect is Boolean, and > it has to be given statically, then in addition, we say that the > static expression is resolved and evaluated at the point of the aspect > specification. Right, seems reasonable > My one bit of discomfort here is for things such as pragma Pack where > we might want to decide it based on something like the 'Size of > something else. E.g: > > type Arr_Of_Elem is array(...) of Elem > with Pack => Elem'Size<= System.Storage_Unit/2; > > This use of 'Size will cause freezing of Elem, so we might like it to > be deferred as long as possible. Perhaps so, at this stage I have all the (quite complex) mechanism in place for doing this, so I am cool either way. I actually find the above example fairly convincing :-) > So perhaps we should limit it further to aspects that require a static > Boolean value and that apply to packages or generic packages. That seems reasonable to me (in fact it is exactly what I have implemented for now :-)) Have we definely agreed to avoid the cancellation mechanism for derived types (that will allow me to remove quite a bit of rather messy implementation junk). **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 4:50 PM > Have we definely agreed to avoid the cancellation mechanism for > derived types (that will allow me to remove quite a bit of rather > messy implementation junk). I believe we disallowed turning off certain things on derived types. In particular, the various aspects relating to shared variables cannot be turned off (e.g. Atomic, Atomic_Components, ...). I forget whether we extended that to cover any other aspects, such as Pack. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:53 PM My recommendation is simply to say that if an aspect is set to False, then it has no effect, i.e. it is as though it were not present at all, and the fact that this means that we are NOT trying to cancel any derived type stuff falls out from this. I don't like going through things one aspect at a time to figure out what the effect is. After all we never had this capability before, and I can't remember anyone ever complaining :-) **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 5:47 PM > My recommendation is simply to say that if an aspect is set to False, > then it has no effect, i.e. it is as though it were not present at > all, and the fact that this means that we are NOT trying to cancel any > derived type stuff falls out from this. That sounds a bit confusing to me. Why would a boolean-valued aspect have this non-overriding behavior for just one of its values, while a non-boolean-valued aspect would have overriding behavior for all of its possible values? > I don't like going through things one aspect at a time to figure out > what the effect is. After all we never had this capability before, and > I can't remember anyone ever complaining :-) I think you will need a better argument than this to convince the rest of the ARG. ;-) **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 6:10 AM Now I am confused, initially I was in favor of cancellation semantics in all cases for derived types, and that is what I have implemented. Now you seem to say the ARG does not want that, I don't really care that much, but it would be nice if people could make up their minds. And I do think it would be best to avoid a lot of special case rules implementing a feature that has never been used. The reason I think the boolean valued stuff is different is that this is NOT providing a value to be used, quite different from size or invariant. It is simply indicating whether the aspect is active or not. Perhaps the whole business of allowing => True at all is wrong, just insist on no parameter at all for these cases, after the whole business of cancellation came up as a surprise when I first raised it :-) **************************************************************** From: John Barnes Sent: Tuesday, November 2, 2010 4:40 AM ... > For me > > package Ada with Pure => True is > end Ada; That's awful. It has that gruesome juxtaposition "is end". ... > Note the pragma is still there, so if this is just asthetics on your > part (note for me there is a real principle about bad pragmas not just > syntax aesthetics), then you can still use the pragma if you want. I am aware that I can still use the pragmas and I would for Pure etc but what I really want to know is are you thinking of going all the way through the RM changing existing text to get rid of the use of pragmas such as Pure? Don't get me wrong, I think that the introduction of these aspect things is a wonderful idea. Pre and postconditions would be hopeless without. But I don't think they are appropriate for Pure etc. You also have to remember that people read each other's programs and it is confusing if different people use gratuitously different styles. **************************************************************** From: Brad Moore Sent: Tuesday, November 2, 2010 10:00 AM > That's awful. It has that gruesome juxtaposition "is end". What if package aspect specifications occurred immediately after the "is" instead of before, and they allowed an extra aspect mark to appear to the left of the with, and the with is optional and only needed if more than one aspect was named. The idea is that programmers would have the flexibility to choose a style that best fits the combination of pragmas they wanted to use. Then I could (and would) write; package Ada is Pure end Ada; This reads very nicely I think. For a different pragma such as Remote_Types, I would use the other format. package Ada is with Remote_Types end Ada; If I wanted to specify both, I would write package Ada is Pure with Remote_Types end Ada; **************************************************************** From: Robert Dewar Sent: Tuesday, November 2, 2010 10:27 AM >>> For me >>> >>> package Ada with Pure => True is >>> end Ada; >>> >> That's awful. It has that gruesome juxtaposition "is end". This makes ZERO sense to me, the aspect stuff does not change that. That "gruesome juxtaposition" has been in Ada since the very beginning, you have always been able to say package Ada is end Ada; that's normal standard syntax, so John's adverse reactions to it are interesting but totally irrelevant to this discussion! > What if package aspect specifications occurred immediately after the > "is" instead of before, and they allowed an extra aspect mark to > appear to the left of the with, and the with is optional and only > needed if more than one aspect was named. > > The idea is that programmers would have the flexibility to choose a > style that best fits the combination of pragmas they wanted to use. > > Then I could (and would) write; > > package Ada is Pure > end Ada; Messy to allow this, given that package Ada is Pure : Integer; end Ada; is quite fine. I really think we should keep the WITH for all aspect specifications, there is no point in creating special syntax for this one case! > This reads very nicely I think. I really do not like the Pure just sitting in the declarative part, it seems odd to me, and even odder is package Ada is Pure Pure : Integer; end Ada; Here we have two identifiers occurring together with no punctuation between them, to see how odd it can become look at package Ada is Pure XYZ, ABC : Integer; end Ada Now it is just the lack of a comma between Pure and XYZ that makes Pure an aspect rather than an Integer variable. You can't seriously think this is a good idea when you see this example :-) > For a different pragma such as Remote_Types, I would use the other > format. > > package Ada is with Remote_Types > end Ada; > > If I wanted to specify both, I would write > > package Ada is Pure > with Remote_Types > > end Ada; Getting even worse in my view, this mixing of two syntaxes is really unpleasant. **************************************************************** From: Robert Dewar Sent: Tuesday, November 2, 2010 11:44 AM To me this syntax looks fine: > 1. pragma Ada_2012; > 2. package aspectpu with Pure is > 3. X : Integer; > | > >>> declaration of variable not allowed in pure unit > > 4. end; **************************************************************** From: John Barnes Sent: Wednesday, November 3, 2010 3:19 AM > This makes ZERO sense to me, the aspect stuff does not change that. > That "gruesome juxtaposition" has been in Ada since the very > beginning, you have always been able to say > > package Ada is > end Ada; > > that's normal standard syntax, so John's adverse reactions to it are > interesting but totally irrelevant to this discussion! I have always hated that and would like the option of saying just package Ada; just as we can say task T; But as you say that is another matter. But it is not irrelevant in the sense that I am against further uglification I would advise against too much choice. Just stick to the with and omit => True. And the elderly can use pragma Pure. But what I really want to know is are we intending to change all the existing uses of pragmas such as Pure to the new syntax? **************************************************************** From: Robert Dewar Sent: Wednesday, November 3, 2010 4:16 AM > But what I really want to know is are we intending to change all the > existing uses of pragmas such as Pure to the new syntax? That's a coding style question, not a language question. Of course the language will retain the pragmas (indeed in GNAT, we have introduced new pragmas such as Invariant and Predicate to take adavtange of these new features in other than Ada 2012 mode). No one is suggesting the obviously unacceptable step of removing the pragmas, and if we did it would be a waste of time, since implementations would leave them in anyway. Note also that the pragmas are a bit more flexible, e.g. Size can appear in the private part, which has methodological and functional implications. **************************************************************** From: Bob Duff Sent: Wednesday, November 3, 2010 8:51 PM > But what I really want to know is are we intending to change all the > existing uses of pragmas such as Pure to the new syntax? You mean existing pragmas Pure in the various language-defined packages in the RM? I've never heard anybody suggest changing those, and I am opposed to changing those (lots of work, no benefit). **************************************************************** From: John Barnes Sent: Thursday, November 4, 2010 3:04 AM > You mean existing pragmas Pure in the various language-defined > packages in the RM? I've never heard anybody suggest changing those, > and I am opposed to changing those (lots of work, no benefit). Good. So all this discussion about with Pure is almost academic. I will ignore it. John **************************************************************** From: Bob Duff Sent: Thursday, November 4, 2010 7:37 AM > Don't get me wrong, I think that the introduction of these aspect > things is a wonderful idea. Pre and postconditions would be hopeless > without. But I don't think they are appropriate for Pure etc. > > You also have to remember that people read each other's programs and > it is confusing if different people use gratuitously different styles. John, I am also somewhat uncomfortable with the push to make everything under the sun into an "aspect". I agree with your "gratuitously different styles" comment. And I think it's a lot of work. (Work that I have apparently been "volunteered" to do...) My list of pragmas was not intended as an endorsement -- I was told to come up with a list of pragmas that might make sense as aspects. The ARG has not yet discussed this list, so there is no official decision that Pure is an aspect. My impression is that everybody on ARG thinks it should be, except you don't like it, and I am ambivalent. To be discussed. Robert wants to rush off and implement it all before the language is designed. He understands that the ARG is still deciding at its usual slow pace. He also understands that implementation-defined aspects are allowed, so Pure can be an aspect without any blessing from ARG, and without using the "-gnatX" (extensions allowed) switch. **************************************************************** From: Robert Dewar Sent: Thursday, November 4, 2010 8:06 AM > Good. So all this discussion about with Pure is almost academic. I > will ignore it. John By no means academic, since I think it will become preferred usage for many Ada programmers. Certainly I will switch the GNAT run-time over to this style in time, since I prefer important semantic effects like this to be achieved with regular syntax rather than pragmas. Also aesthetically, I prefer package Types with Pure is type Int is new Integer; ... end Types; to package Types is pragma Pure; type Int is new Integer; ... end Types; since, never mind the pragma issue, the latter form makes the pragma look like one of the declarations inside the package, rather than setting an attribute of the package itself. BTW, this form is now fully implemented in GNAT **************************************************************** From: Bob Duff Sent: Thursday, November 4, 2010 8:25 AM > Certainly I will switch the GNAT run-time over to this style in time, > since I prefer important semantic effects like this to be achieved > with regular syntax rather than pragmas. Pragmas that place restrictions on what you can do (via compile-time or run-time checked -- doesn't matter) are OK by me. Pure is mostly (not entirely) in that category. Pragma Restrictions is the most obvious one. You could imagine "pragma Restrictions (No_Impure_Stuff);" which would mean roughly the same as "pragma Pure". **************************************************************** From: Robert Dewar Sent: Thursday, November 4, 2010 8:32 AM Right, I would prefer that all such pragmas (ones that serve simply to place restrictions on what can be done), be spelled Restriction or Profile, and that other pragmas that are in effect restrictions be avoided. And as you say, Pure goes a bit beyond this :-) I also prefer the clarity of the aspect pure being syntactically connected to the package, rather than appearing like the pragma to be merely one of the components of the package syntactically. **************************************************************** From: John Barnes Sent: Sunday, November 7, 2010 8:07 AM > Perhaps the whole business of allowing => True at all is wrong, just > insist on no parameter at all for these cases, after the whole > business of cancellation came up as a surprise when I first raised it > :-) Yes, that seems to be the nub of the issue. Cut out the => True. **************************************************************** From: Brad Moore Sent: Thursday, November 11, 2010 10:00 AM > I also prefer the clarity of the aspect pure being syntactically > connected to the package, rather than appearing like the pragma to be > merely one of the components of the package syntactically. I have the following library level generic instantiation. with Buffers.Simple_Unbounded; package String_Buffers.Simple_Unbounded_Buffer is new String_Buffers.Simple_Unbounded; pragma Preelaborate (String_Buffers.Simple_Unbounded_Buffer); pragma Remote_Types (String_Buffers.Simple_Unbounded_Buffer); Presumably, I'd now be able to write instead; with Buffers.Simple_Unbounded; package String_Buffers.Simple_Unbounded_Buffer with Remote_Types, Preelaborate is new String_Buffers.Simple_Unbounded; without having to respecify the package name on each of the aspects. That is quite a bit cleaner than the pragma version. **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 10:18 AM > without having to respecify the package name on each of the aspects. > That is quite a bit cleaner than the pragma version. I don't understand this, if this is indeed intended, it is a surprise to me. To me the aspect was just a syntactic equivalent for the pragma in a case like this. **************************************************************** From: Tucker Taft Sent: Thursday, November 11, 2010 11:03 AM > Presumably, I'd now be able to write instead; > > with Buffers.Simple_Unbounded; > > package String_Buffers.Simple_Unbounded_Buffer with Remote_Types, > Preelaborate is new String_Buffers.Simple_Unbounded; The syntax in 12.3 indicates that the aspect specification comes just before the ";" in an instantiation. Hence: package String_Buffers.Simple_Unbounded_Buffer is new String_Buffers.Simple_Unbounded with Remote_Types, Preelaborate; >> without having to respecify the package name on each of the aspects. >> That is quite a bit cleaner than the pragma version. > > I don't understand this, if this is indeed intended, it is a surprise > to me. To me the aspect was just a syntactic equivalent for the pragma > in a case like this. I don't understand what you don't understand ;-). Brad is pointing out an example of how the aspect specification can be cleaner (syntactically, I presume he means) than a categorization or elaboration-control pragma. Other than the positioning of the aspect clause, his example seems valid. **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 12:44 PM > I don't understand what you don't understand ;-). Brad is pointing > out an example of how the aspect specification can be cleaner > (syntactically, I presume he means) than a categorization or > elaboration-control pragma. Other than the positioning of the aspect > clause, his example seems valid. Ah because of the mispositioning, I missed them entirely glancing at his example, and thought he was somehow suggesting that they got inherited from the aspects of the template :-) > It is interesting to imagine extending the syntax to allow aspect > specifications on "with" clauses: > > with Ada.Text_IO > with Elaborate_All; > > Someone else might have already mentioned the issue with this > extension creating an error prone situation where leaving off a ";" > will produce a significantly different interpretation! > > Probably not worth going there... Don't like this idea at all. Bad enough to have WITH meaning two such very different things, and to put these conflicting uses into close alliance is a mistake (the phenomenon of the missing semicolon just reemphasizes the basic mistake The worse case is with Ada.Text_IO with My_Package; where now presumably you get a diagnostic saying My_Package is not a valid aspect name, instead of missing semicolon (and of course it's even worse if the name of the second package *does* happen to match an aspect name, as in with Ada.Text_IO with Size; | missing => or with Ada.Text_IO with Inline; | Inline aspect cannot be applied to package **************************************************************** From: John Barnes Sent: Thursday, November 11, 2010 5:42 PM from brief glimpses of this thread from a tropical rainforest in Queensland there seems to me to be a risk of with A_Mess; **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 7:07 PM Sorry I don't get your reaction at all, my query was answered completely, and I don't see any problem at all? **************************************************************** From: John Barnes Sent: Friday, November 12, 2010 5:21 AM Well, I did say I only had brief glimpses but it did seem that there was the risk of confusion with multiple use of with. And I continue to be cautious of providing multiple ways of doing one thing with concern for those who have to maintain software. If the standard libraries continue to have pragmas for pure, remote types etc, it could be a muddle for new user code to do those things a different way. Maybe we should move all the pragmas to J and rewrite the existing standard packages?? And it could add even more wretched pages to a certain book!! **************************************************************** From: Robert Dewar Sent: Friday, November 12, 2010 8:11 AM > Maybe we should move all the pragmas to J and rewrite the existing > standard packages?? I find this a waste of time. In fact the pragmas have uses not satisfied by the aspects and vice versa, I think it is fine to have both forms. And moving things to Annex J is always a waste of time, these things are not going away, and it would be unhelpful for pragma Restrictions (No_Obsolescent_Features) to ban all these pragmas, which are pervasive in the existing Ada code base. **************************************************************** From: Robert Dewar Sent: Friday, November 12, 2010 8:12 AM > Well, I did say I only had brief glimpses but it did seem that there > was the risk of confusion with multiple use of with. Please don't condition your response on a suggestion that there is no real enthusiasm for and which even the suggester disavows (allowing aspect on WITH clause). **************************************************************** From: Bob Duff Sent: Sunday, January 23, 2011 6:19 PM 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)? I don't see anything about this in the Nov phone meeting minutes. Anyway, I think somebody in the "Everything's an Aspect" school of thought ought to take over the main authorship of this AI. The above "with a few topics" is really referring to pretty-much everything. **************************************************************** From: Randy Brukardt Sent: Monday, January 24, 2011 10:14 PM > Maybe the CPU thing should be ONLY an aspect (since everybody seems to > prefer aspects nowadays)? I don't think that there is anything general that needs to be said about pragmas. Remember that there is supposed to be an entire annex listing specifiable aspects. (That's the job I need to do, which is to discuss with you the best form of that annex. I'll do that off-line here.) As far as CPU goes, I thought we had decided to dump the pragma. But I obviously didn't record that, so we'll probably have to talk about it again. ... > Anyway, I think somebody in the "Everything's an Aspect" > school of thought ought to take over the main authorship of this AI. > The above "with a few topics" is really referring to pretty-much > everything. No, someone still has to write the text for the introduction to the aspect annex and to suggest a common form for the entries in that annex. My job is just to verify that it can be automated (we want it to work like the attribute annex in terms of the actual source code). So that is more than just the stuff assigned to Tucker. The real problem is that I don't think we have anyone else that we can count on to get the work done in a timely fashion. If you can find someone else to take it over, I won't mind presuming that person isn't named Tucker. :-) **************************************************************** From: Bob Duff Sent: Tuesday, January 25, 2011 9:55 AM > I don't think that there is anything general that needs to be said > about pragmas. I already wrote something general for representation pragmas. People complained that it doesn't cover Inline and CPU. (Others?) >...Remember that there is supposed to be an entire annex listing >specifiable aspects. (That's the job I need to do, which is to discuss >with you the best form of that annex. I'll do that off-line here.) > > As far as CPU goes, I thought we had decided to dump the pragma. But I > obviously didn't record that, so we'll probably have to talk about it again. If you mean CPU should be an aspect instead of a pragma, then I think that's a good idea, and I do (vaguely) remember discussing that. I think there are two AI's that mention this pragma -- the one that defines it, and the one about dispatching domains that I took over from Alan. > ... > > Anyway, I think somebody in the "Everything's an Aspect" > > school of thought ought to take over the main authorship of this AI. > > The above "with a few topics" is really referring to pretty-much > > everything. > > No, someone still has to write the text for the introduction to the > aspect annex and to suggest a common form for the entries in that > annex. My job is just to verify that it can be automated (we want it > to work like the attribute annex in terms of the actual source code). > So that is more than just the stuff assigned to Tucker. As I said privately, I'm not convinced such an Annex is necessary. I already sent you an "introduction" privately. No big deal. As to the entries, I wouldn't do them like attributes (where the entire text is duplicated in the annex). I'd just put a command like: @aspect{CPU, "The CPU on which to execute a task."} immediately before/after the place where CPU is defined. This would generate no text inline, and generate alphabetized text in the Annex. > The real problem is that I don't think we have anyone else that we can > count on to get the work done in a timely fashion. If you can find > someone else to take it over, I won't mind presuming that person isn't > named Tucker. :-) 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=[],Kind=[],Aspect=[],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? **************************************************************** From: John Barnes Sent: Wednesday, February 16, 2011 4:07 AM I am sorry not to be with you again at the meeting in sunny Florida. Although improving, I am still very reluctant to fly. I am especially annoyed at missing the opportunity to see the new Dali museum. In my absence, Jeff Cousins is taking my place. I am sure I will see you all in Edinburgh. Meanwhile, please read the following: As you will have perceived from reading the latest draft of the Rationale I am unhappy with two areas of Ada 2012. One is some aspects of aspects (groan); the other is subtype predicates.. [For the predicate part of the discussion, see AI05-0153-3.] Aspects. Although the use of the new aspect syntax is excellent for attaching properties to subprograms, there are misgivings with other uses and especially when replacing pragmas relating to packages, task and protected objects by aspects. One problem is the overuse of with. The definition of the protected type Queue in Unbounded_Synchronized_Queues is now protected type Queue(Ceiling: Any_Priority := Default_Ceiling) with Priority => Ceiling is new Queue_Interfaces.Queue with .... etc In close proximity we have two quite different uses of "with". Moreover, a few lines above we have "with System" and "with package Queue_Interfaces". So altogether four different uses of "with". Clearly we cannot do anything about three of them. This could be solved by introducing another reserved word for aspects. But somehow I doubt whether we will find one we like. Alternatively this can be solved by reverting to the use of pragmas in this situation thus protected type Queue(Ceiling: Any_Priority := Default_Ceiling) is new Queue_Interfaces.Queue with pragma Priority(Ceiling); .... etc I further understand from Alan that the Real-Time community and especially the IRTAW group are perfectly happy with the use of pragmas for features such as Priority and would not want to change. Moreover, for new features such as CPU they want to use a pragma for consistency with the things such as Priority. There is no objection to the introduction of an aspect for CPU as well but the pragma is definitely required. We should heed and take action on their request. **************************************************************** From: Robert Dewar Sent: Wednesday, February 16, 2011 7:11 AM > Although the use of the new aspect syntax is excellent for attaching > > properties to subprograms, there are misgivings with other uses and > > especially when replacing pragmas relating to packages, task and > protected > > objects by aspects. Hmmm, these are uses which seem very natural and convenient to me, I much prefer package X with Pure is .. to package X is pragma Pure; oh well ... tastes differ, the pragmas are still there of course. I suppose we could remove them, the same way we removed all the Ada 83 pragmas, knowing that implementations would put them back anyway :-) It would leave the language definition cleaner to do this without compromising portability in practice, and as I say, we do have a precedent for this action. > I further understand from Alan that the Real-Time community and > especially the IRTAW group are perfectly happy with the use of pragmas for > features such as Priority and would not want to change. I doubt anyone can speak for "the Real-Time community", certainly IRTAW does not have strong contacts with many commercial embedded real time producers. I expect that in practice some will use the pragmas and some will switch to the aspects. For myself, I prefer the use of aspects in all cases, and I don't find the extra use of WITH confusing, it is easy for the parser and easy for at least this human to distinguish the uses. > Moreover, for new features > such as CPU they want to use a pragma for consistency with the things > such as Priority. There is no objection to the introduction of an aspect > for CPU as well but the pragma is definitely required. Well I am not sure I would pay too much attention to the particular tastest of one particular group, and in any case certainly GNAT will have both anyway, I would be opposed to adding both to Ada 2012, that's unnecessary redundancy. > We should heed and take action on their request. When it comes to aesthetic choices between two equivalent syntaxes, you will always find people who strongly prefer one and others who strongly prefer the other. That's not a reason to put both in the language! **************************************************************** From: Bob Duff Sent: Wednesday, February 16, 2011 8:51 AM Randy has to file these emails in the appropriate AI, so we should have one subject per email. I'll reply to your "aspect" comments here, and send a separate email about "predicates". > I am sorry not to be with you again at the meeting in sunny Florida. We'll miss you! > Aspects. > > Although the use of the new aspect syntax is excellent for attaching > properties to subprograms, there are misgivings with other uses and > especially when replacing pragmas relating to packages, task and > protected objects by aspects. I agree with you, regarding type extensions -- the two "with"s are slightly jarring. But I don't think it's a big deal, and I haven't seen any better proposals, and I haven't been able to come up with anything better myself. I disagree with you about packages, tasks, and protecteds. There, the with clauses seem sufficiently separated from the aspect clauses. > I further understand from Alan that the Real-Time community and > especially the IRTAW group are perfectly happy with the use of pragmas > for features such as Priority and would not want to change. Moreover, > for new features such as CPU they want to use a pragma for consistency > with the things such as Priority. There is no objection to the > introduction of an aspect for CPU as well but the pragma is definitely required. I have mixed feelings about that. Obviously, if Priority is an aspect, we need to keep the pragma for compatibility reasons. I was planning to make CPU and Dispatching_Domain into aspects, and drop the pragmas. But before I got a chance to write that up, Alan argued against that, so I decided not to write anything up, but see what folks think at the meeting. Two things bother me about having both. It's a pain to write the RM wording. And I hate to see the language split into two dialects, some folks refusing to use aspects, and others refusing to use pragmas. It's like "in" on parameters. Three dialects in that case -- (1) always say "in", (2) never say "in", (3) "in" on procedures, not on functions. There is no value in allowing these kinds of choices. **************************************************************** From: Randy Brukardt Sent: Wednesday, February 16, 2011 11:35 AM If you are not going to write up something, it would be best if you told your editor so he did not think you were shirking your work. I spent most of yesterday doing it. I ended up leaving the pragmas as aspects are not allowed on subprogram bodies. This has to be done at this meeting and doing this wording at night is not practical. (Sending mail from my phone is such fun.) **************************************************************** From: Bob Duff Sent: Wednesday, February 16, 2011 11:58 AM > If you are not going to write up something, it would be best if you > told your editor so he did not think you were shirking your work. But I WAS shirking (sorry). At least I completed all my other homework. > I spent most of yesterday doing it. Thanks. >...I ended up leaving the pragmas as > aspests are not allowed on subprogram bodies. This has to be done at >this meeting and doing this wording at night is not practical. OK. I was having trouble seeing how to do that without duplicating a lot of wording (which is part of my reason for shirking), so I'll look forward to seeing what you did. > (Sending mail from my phone is such fun.) I don't know how to send mail from a phone! **************************************************************** From: John Barnes Sent: Friday, February 18, 2011 7:42 AM > I have mixed feelings about that. Obviously, if Priority is an > aspect, we need to keep the pragma for compatibility reasons. > > I was planning to make CPU and Dispatching_Domain into aspects, and > drop the pragmas. But before I got a chance to write that up, Alan > argued against that, so I decided not to write anything up, but see > what folks think at the meeting. > > Two things bother me about having both. It's a pain to write the RM > wording. And I hate to see the language split into two dialects, some > folks refusing to use aspects, and others refusing to use pragmas. > It's like "in" on parameters. Three dialects in that case -- (1) > always say "in", (2) never say "in", > (3) "in" on procedures, not on functions. There is no value in > allowing these kinds of choices. I don't mind having both aspects and pragmas for CPU and Dispatching_Domain. I shouldn't have thought it was too much of a bother about the wording because you can presumably use the same arrangement as has to be used for Priority. In general I don't like two ways of doing the same thing because it means that programmers use different styles and that can make it harder for program maintenance. But we have added several features in the past that have resulted in two ways to do things. An obvious example is the prefix notation for subprogram calls. Good marketing no doubt and I don't disagree with it at all. Another example is introducing anonymous access types. Maybe that was meant to be for marketing as well; but it gave us lots of accessibility pain and made writing my book rather confusing. In a sense this is a marketing issue as well. We don't want to upset the real-time folks if they are happier with pragmas. Of course, generally aspects are wonderful. The first attempt to do pre and post conditions with pragmas was truly gruesome. So my preference is to give them both. **************************************************************** From: Robert Dewar Sent: Friday, February 18, 2011 8:00 AM >> I have mixed feelings about that. Obviously, if Priority is an >> aspect, we need to keep the pragma for compatibility reasons. As I said in a previous message, this is not obvious at all. We dropped Ada 83 pragmas knowing that implementors would keep them. ... > I don't mind having both aspects and pragmas for CPU and Dispatching_Domain. > I shouldn't have thought it was too much of a bother about the wording > because you can presumably use the same arrangement as has to be used > for Priority. > > In general I don't like two ways of doing the same thing because it > means that programmers use different styles and that can make it > harder for program maintenance. But we have added several features in > the past that have resulted in two ways to do things. An obvious > example is the prefix notation for subprogram calls. Good marketing no > doubt and I don't disagree with it at all. Another example is > introducing anonymous access types. Maybe that was meant to be for > marketing as well; but it gave us lots of accessibility pain and made writing my book rather confusing. > > In a sense this is a marketing issue as well. We don't want to upset > the real-time folks if they are happier with pragmas. Please don't assume that the aesthetic tastes of a few represent the wishes of the "real=time folks". We do a lot because of personal preferences (Tuck doesn't like IN OUT function parameters unless we have strange rules about side effects, Randy doesn't like one aspect for predicates etc). Not terrible, and probably not so important, since compilers are in the business of accomodating multiple tastes anyway (GNAT already has three predicates: Static_Predicate Dynamic_Predicate Predicate the latter impl-defined, is like static predicate if it meets the rules for SP, and otherwise like dynamic predicate. > Of course, generally aspects are wonderful. The first attempt to do > pre and post conditions with pragmas was truly gruesome. Doesn't seem so gruesome to me, and will always be available in GNAT (big advantage over aspects, you can use them in Ada 95 and Ada 2005, which is why we always provide pragmas as well, although I abandoned pragma Predicate as too hard to implement at the time, but might revisit it). > So my preference is to give them both. Well don't spend too much anguish over the decision, for quite a while (for ever?) all the Ada 2012 compilers in the world will implement both forms whatever the ARG decides :-) **************************************************************** From: Brad Moore Sent: Saturday, February 19, 2011 8:04 AM An editorial comment: The AARM note in the wording section says " The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28)" yet the AI is about adding the ability to specify aspects for these (except CPU?). I suspect this section needs updating. [Editor's note: I think he was reading something old; there is no such text in the body of the AI as of Feb. 14.] I hope the meeting in Tampa is going well, and sorry I cannot be there. I am in Montreal this weekend, my daughter is applying at McGill. **************************************************************** 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 Indeed this is huge and needs a quiet weekend in bed with a mild infection such as gout. However, on a quick skim through all seems OK. But I wonder why Preelaborable_Initialization is not left as a pragma like Pure etc. It sems to be the same sort of thing. Could confuse and puzzle users. Maybe it's just me and because I describe these things in the same section of my book. **************************************************************** From: Randy Brukardt Sent: Thursday, April 7, 2011 11:49 AM The strategy is that types, objects, and subprograms always use aspects rather than pragmas, while packages use pragmas. Thus P_I (which works on types) is described as an aspect. This should be a fairly easy rule to describe to your readers. **************************************************************** From: Robert Dewar Sent: Friday, April 8, 2011 6:13 PM GNAT will provide pragmas as well as aspects for all these kinds of things, so that they can be used in other than Ada 2012 mode, and in any case we implement aspects by translating them to the corresponding pragmas or attribute definition clauses. So in terms of actual use, it won't make a difference what the language decices here. **************************************************************** From: John Barnes Sent: Monday, April 11, 2011 5:27 AM However, the recent phone meeting changed Preelaborable_Initialization to remain just as a pragma. Nothing to do with my book, but to do with views. **************************************************************** From: John Barnes Sent: Tuesday, April 12, 2011 11:05 AM Am I right in assuming that we prefer to say "the aspect Whatever" rather than "the Whatever aspect"? However, AI-229 has a few instances of the second. Particularly "the Pack aspect". **************************************************************** From: Ed Schonberg Sent: Tuesday, April 12, 2011 11:15 AM I raised that question at the last phone meeting. My preference is for "aspect Whatever" but I was told that no single form has been adopted, and it was up to the ear of whoever wrote a particular paragraph. Personally I prefer the first form. **************************************************************** From: Tucker Taft Sent: Tuesday, April 12, 2011 11:26 AM I would vote for either "aspect Blah" or "the Blah aspect." Adding "the" in front of "aspect Blah" doesn't sound right to me. **************************************************************** From: John Barnes Sent: Tuesday, April 12, 2011 11:57 AM Well the AI is riddled with all sorts of aspects. Some with the and some without. There are lots of "the aspect Blah". **************************************************************** From: Randy Brukardt Sent: Tuesday, April 12, 2011 1:24 PM With AI05-0229-1, I preferred to say whatever made the least change to the existing wording (didn't want to introduce bugs with this rewording). When possible, that just meant changing "pragma" to "aspect". And there is no consistency about how pragmas are identified in text. Note that at least 4 people worded parts of this AI over about 2 months, and the wording being changed is in very many different styles, so the styles aren't that consistent. And in any case it has not been approved or reviewed yet, I still have to apply the changes from the phone meeting to it. So presume it will change some more (but not too drastically). P.S. I'd just as soon this AI got reviewed before I put it into the Standard, so if you are finding specific things to change, please point them out. **************************************************************** From: Robert Dewar Sent: Wednesday, April 13, 2011 8:15 AM > I would vote for either "aspect Blah" or "the Blah aspect." > Adding "the" in front of "aspect Blah" doesn't sound right to me. I agree with Tuck, and I don't see a need to force consistency, the choice of which of these sounds nicer depends on the circumstance. **************************************************************** From: Erhard Ploedereder Sent: Sunday, May 15, 2011 11:31 AM [The appropriate part of a longer message - Editor.] AI05-0229-1/09 Specifiable aspects [Changes from phone meeting: moved xxx_components aspect to be array type only; removed Preelaborable_Initialization (it will remain a pragma); added legality rules to prevent various aspects from being specified on interfaces; added change of pragma Convention to an aspect in predefined packages.] Approve ______ Disapprove __X____ Abstain _______ ===================== > 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. surely it is not a pragma that is specified. (and stacking the "that"s 3-deep is not nice). Suggested Rewrite: Any aspect specified by a representation pragma or library unit pragma that has a local_name as its single argument 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. > If directly specified, the aspect_definition shall be a static expression. > [Redundant: This aspect is never inherited;] .... Why is this redundant? 13.1 (15/1) says exactly the opposite. It is a representational aspect after all. Same comment for Inline and possibly others. > Replace C.6(10) with the following two paragraphs: > If one of these aspects is specified for a component_declaration, the > declaration shall not be inherited. Ambiguous wording. Can be read as an inheritance rule (hiding the component) rather than an aspect rule. And: how can I refer to a syntactic component_declaration when the component/declaration is inherited? Suggested rewrite: "It is illegal to specify any one of these aspects for an inherited component." **************************************************************** From: Brad Moore Sent: Sunday, May 15, 2011 2:54 PM [The appropriate part of a longer message - Editor.] > AI05-0229-1/09 Specifiable aspects > [Changes from phone meeting: moved xxx_components aspect to be array type only; > removed Preelaborable_Initialization (it will remain a pragma);added legality > rules to prevent various aspects from being specified on interfaces; added > change of pragma Convention to an aspect in predefined packages.] > Approve ___X___ Disapprove ______ Abstain _______ Editorial Comment: In the AI, in the wording section of the AI, there is discussion stating the P_I is not appropriate as an aspect and will only be available as a pragma. However, in the discussion section under the heading "Pragmas that could be Boolean operational or Representational aspects:" it still lists P_I. **************************************************************** From: Randy Brukardt Sent: Tuesday, May 17, 2011 2:11 AM ... > > 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. > > surely it is not a pragma that is specified. (and stacking the "that"s > 3-deep is not nice). Suggested Rewrite: > > Any aspect specified by a representation pragma or library unit pragma > that has a local_name as its single argument 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. Looks like an improvement to me, so I used it. > > If directly specified, the aspect_definition shall be a static expression. > > [Redundant: This aspect is never inherited;] .... > > Why is this redundant? 13.1 (15/1) says exactly the opposite. > It is a representational aspect after all. Same comment for Inline and > possibly others. I presume you are talking about No_Return here (you didn't say). Anyway, that is a subprogram aspect; 13.1(15/1) is only talking about type aspects and derived types. There is no inheritance defined for other kinds of entities. As I mentioned in another message, maybe there should have been, but in general we don't need it for subprogram aspects. Inline in particular is *not* inherited. And unlike No_Return, there is no mechanism for it to be inherited. (Since it applies effectively to bodies, there isn't any reason for it to be inherited, either.) Similarly, preconditions and postconditions aren't inherited. (Class-wide ones "apply" to descendants, but they aren't inherited either; this allows new ones to be additively specified, which is what we want.) > > Replace C.6(10) with the following two paragraphs: > > If one of these aspects is specified for a component_declaration, > > the declaration shall not be inherited. > > Ambiguous wording. Can be read as an inheritance rule (hiding the > component) rather than an aspect rule. And: how can I refer to a > syntactic component_declaration when the component/declaration is > inherited? > > Suggested rewrite: > "It is illegal to specify any one of these aspects for an inherited > component." I think you were right with your first idea: it's not possible to specify an aspect on an inherited component_declaration, because it is not syntactically there. I was too literal in my translation of the old rules - that was a problem when the name (alone) is specified in a pragma, but not when the entire syntax has to appear (because that, by definition, is not inherited). So I just deleted the sentence completely and fixed up the corresponding editor's note. -------------------- I'm a bit surprised that you voted against this AI, as none of the technical objections rise much beyond editorial questions. Was there some other objection that you didn't voice?? **************************************************************** From: Erhard Ploedereder Sent: Tuesday, May 17, 2011 12:16 PM > I'm a bit surprised that you voted against this AI, as none of the technical > objections rise much beyond editorial questions. Was there some other > objection that you didn't voice?? Not at the time, but now I have. All of the pragmas turned into respresentational aspects, none into operational aspects; the summary suggests that there are operational ones, too. (A consequence of cut-and-paste or deliberate?) Certainly Inline or No_Return do strike me as being perfectly operational aspects (which, incidently, are specified as non-inherited, which would justify the "Redundant"-phrases ;-)) The AI started out with me as an "Approve with comment", but we did not have this category. Also, I was not sure whether the "Redundant" comments would not merit further discussion as to why these were redundant. I still think that, for representational attributes, they are not, because out of not specifying inheritance of an aspect at all one cannot deduce non-inheritance, strictly speaking. (Just because nothing is said about it, you cannot conclude that I am not German.) But I guess, this is not the important discussion to have. I would like to further discuss whether they are operational aspects. A simple answer would be to make them operational aspects, along with many others. In fact, apart from Storage_Size and most of the boolean attributes, the listed pramas have the flavor of operational rather than representational aspects. **************************************************************** From: Randy Brukardt Sent: Tuesday, May 17, 2011 2:30 PM > > I'm a bit surprised that you voted against this AI, as none of the technical > > objections rise much beyond editorial questions. Was there some > > other objection that you didn't voice?? > > Not at the time, but now I have. All of the pragmas turned into > respresentational aspects, none into operational aspects; the summary > suggests that there are operational ones, too. (A consequence of > cut-and-paste or deliberate?) I think the summary was written first; it should be fixed. Anyway, the main issue is that Ada has no concept of "operational pragma", only of "representation pragma". In order for any of these to be operational aspects, the pragma classification would need to be changed, which would require a bunch of extra wording in 13.1 (so that the important rules against duplication would clearly apply). This would have been doable, but I was trying (as usual) to make the minimum changes here. > Certainly Inline or No_Return do strike me as being perfectly > operational aspects (which, incidently, are specified as > non-inherited, which would justify the "Redundant"-phrases ;-)) No_Return is currently defined as a representation pragma. Changing it to something else seemed like churn. Inline is a library unit pragma, so it wouldn't have that problem. But "inlining" seemed very representational to me (it has to do with the representation of the body); the idea of operational aspects was for stuff that didn't have a direct impact on the form of an entity. So this seems more operational than representational. > The AI started out with me as an "Approve with comment", but we did > not have this category. Also, I was not sure whether the "Redundant" > comments would not merit further discussion as to why these were > redundant. I still think that, for representational attributes, they > are not, because out of not specifying inheritance of an aspect at all > one cannot deduce non-inheritance, strictly speaking. > (Just because nothing is said about it, you cannot conclude that I am > not German.) But I guess, this is not the important discussion to > have. My opinion is that if the RM doesn't explicitly state something, then it doesn't exist. If we start "inferring" semantics from wording about other kinds of entities, we are going to have a lot of trouble. Perhaps 13.1 should have a sentence saying that there is no inheritance unless described explicitly, but that seems to me to do without saying. We don't have to say that a float type is not a descendant of type Integer! (Or more generally, we don't have to say that a float type is not a descendant of any type other than root_real.) The meaning of "inheritance" is exactly what the RM says it is, and nothing more. It is a common problem in the wording that someone assumes "inheritance" or "pragma applies" or terms like that are usable outside of their existing narrow contexts. There have been a lot of fixes like that (Adam complaining about that is what started AI05-0215-1, to take one recent example). > I would like to further discuss whether they are operational aspects. > A simple answer would be to make them operational aspects, along with > many others. In fact, apart from Storage_Size and most of the boolean > attributes, the listed pramas have the flavor of operational rather > than representational aspects. That might be, but they are almost all previously defined as representation pragmas. And we don't have a concept of "operational pragma", so changing these seemed like churn to me. Also note that for types, "operational aspects" are allowed on private types, "representational aspects" are not. For things like Priority, we don't want to have to define rules for allowing them on private types, and I don't think we want to muddle the rules by allowing some but not all operational aspects on private types (that would require quite a bit of change in 13.1). So they too end up as representational aspects. As I mentioned in reply to Tucker, it would make a lot of sense to have additional flavors of aspects (categorization aspects don't seem much like either of the existing categories, for instance), but that is pretty complicated to define and doesn't seem worth the effort. **************************************************************** From: Tucker Taft Sent: Monday, May 2, 2011 9:44 PM [The appropriate part of a longer message - Editor.] AI05-0190-1/11 Global storage pool controls [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.] Approve __X____ Disapprove ______ Abstain _______ Comments: Should we move pragma Controlled to the obsolescent Annex? **************************************************************** From: Randy Brukardt Sent: Monday, May 2, 2011 10:32 PM > Should we move pragma Controlled to the obsolescent Annex? AI05-0229-1 does that. **************************************************************** From: Tucker Taft Sent: Tuesday, May 3, 2011 2:04 PM What I actually meant was to move the whole kit-and-kaboodle to Annex J. That is, move the Controlled aspect, pragma, etc. to Annex J. In other words, 13.11.3 would disappear and reappear in Annex J. Perhaps that is too radical? Do *any* Ada compilers support the "Controlled" pragma/aspect? Our Ada->Java-byte-code compiler supports garbage collection, but we don't have any way of turning it off. **************************************************************** From: Randy Brukardt Sent: Tuesday, May 3, 2011 2:51 PM > What I actually meant was to move the whole kit-and-kaboodle to Annex > J. That is, move the Controlled aspect, pragma, etc. to Annex J. In > other words, 13.11.3 would disappear and reappear in Annex J. Perhaps > that is too radical? It's pretty radical for the last minute. OTOH, as a pragma, we don't even have to move it to annex J. If we don't want the feature anymore, it can just go "poof"! And I agree that it doesn't do anything useful (other than perhaps promise capabilities that can't really be delivered in stock Ada - we don't have a permission to finalize early, so anything that might be controlled cannot be garbage collected). We have plenty of precident for "poof" in Ada 95 (pragma Memory_Size and System_Name, also never implemented). > Do *any* Ada compilers support the "Controlled" pragma/aspect? > Our Ada->Java-byte-code compiler supports garbage collection, but we > don't have any way of turning it off. I don't know of any. That suggests "poof" is a good option... **************************************************************** 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. As a pragma, we wouldn't even need to move this to Annex J; it could simply disappear. Probably the only real benefit of 13.11.3 is that it gets the term "garbage collection" in the Standard and index, so that everyone can find out that Ada doesn't have it. ;-) Anyway, it is pretty late to consider this, but since I haven't yet done the work to "aspectize" it in the draft Standard, we still can move the whole thing to Annex J or delete it outright if we want. So here's another straw poll: Please rank these options from 1 to 4, with 1 being the most preferred and 4 being the least. _______ Remove 13.11.3 (Pragma Controlled) completely from the standard. _______ Move the entire contents of 13.11.3 to Annex J, do not make it an aspect. _______ Move the entire contents of 13.11.3 to Annex J, but still make it an aspect. _______ Make pragma Controlled into an aspect, move just the pragma to Annex J (the solution currently approved in AI05-0229-1). **************************************************************** From: Randy Brukardt Sent: Friday, May 6, 2011 12:47 AM And here's my ballot: ... > Please rank these options from 1 to 4, with 1 being the most preferred > and 4 being the least. > > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the > standard. > > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make > it an aspect. > > ___3____ Move the entire contents of 13.11.3 to Annex J, but still > make it an aspect. > > ___4____ Make pragma Controlled into an aspect, move just the pragma > to Annex J (the solution currently approved in AI05-0229-1). **************************************************************** From: Robert Dewar Sent: Friday, May 6, 2011 4:25 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. Not now, but it is always something that might be done in the future > > As a pragma, we wouldn't even need to move this to Annex J; it could > simply disappear. > > Probably the only real benefit of 13.11.3 is that it gets the term > "garbage collection" in the Standard and index, so that everyone can > find out that Ada doesn't have it. ;-) > > Anyway, it is pretty late to consider this, but since I haven't yet > done the work to "aspectize" it in the draft Standard, we still can > move the whole thing to Annex J or delete it outright if we want. > > So here's another straw poll: > > Please rank these options from 1 to 4, with 1 being the most preferred > and 4 being the least. My preference isn't even here, which is do nothing at all. this is undoubtedly what GNAT will do anyway. I think it is plain silly to make this into an aspect, extra work for implementations and the standard for absolutely no gain whatever. Any of the solutions above has the disadvantage of being extra work I don't like any of them >> >> __2_____ Remove 13.11.3 (Pragma Controlled) completely from the standard. Well easy enough to implement, any implementation that followed suit would be wasting its time, certainly we wouldn't bother in GNAT, though I guess this technically would force us to add to the Annex M documentation. >> >> __1_____ Move the entire contents of 13.11.3 to Annex J, do not make >> it an aspect. Well that's zero work to implement and document, and I guess minimal work for the standard effort, so if we have to choose one of these, this is the best >> >> __3_____ Move the entire contents of 13.11.3 to Annex J, but still >> make it an aspect. Better than 4 below, but still wastes everyones time >> >> __4_____ Make pragma Controlled into an aspect, move just the pragma >> to Annex J (the solution currently approved in AI05-0229-1). Wastes everyones time **************************************************************** From: Jean-Pierre Rosen Sent: Friday, May 6, 2011 5:21 AM > Please rank these options from 1 to 4, with 1 being the most preferred > and 4 being the least. > > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard. > > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make > it an aspect. > > ___3____ Move the entire contents of 13.11.3 to Annex J, but still > make it an aspect. > > ____4___ Make pragma Controlled into an aspect, move just the pragma > to Annex J (the solution currently approved in AI05-0229-1). > I think pragma Controlled is actively harmful, I only saw it used by people who did not understand its (none) effect, and who were expecting from it properties that it did not ensure. Making it into an aspect would be some kind of blessing that it does mean something - which it doesn't. **************************************************************** From: Bob Duff Sent: Friday, May 6, 2011 5:53 AM > And here's my ballot: > > ... > > Please rank these options from 1 to 4, with 1 being the most > > preferred and 4 being the least. > > > > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the > > standard. > > > > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make > > it an aspect. > > > > ___3____ Move the entire contents of 13.11.3 to Annex J, but still > > make it an aspect. > > > > ___4____ Make pragma Controlled into an aspect, move just the pragma > > to Annex J (the solution currently approved in AI05-0229-1). My vote is identical to Randy's, above. I think the idea of (1) is that implementations will keep doing exactly what they're doing, presumably keeping pragma Controlled as an impl-def pragma. **************************************************************** From: John Barnes Sent: Friday, May 6, 2011 5:55 AM > Please rank these options from 1 to 4, with 1 being the most preferred > and 4 being the least. > > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard. > > ____2___ Move the entire contents of 13.11.3 to Annex J, do not make > it an aspect. > > _____3__ Move the entire contents of 13.11.3 to Annex J, but still > make it an aspect. > > ____4___ Make pragma Controlled into an aspect, move just the pragma > to Annex J (the solution currently approved in AI05-0229-1). Yes, lets get rid of the wretched thing. That saves 4 lines in my book. **************************************************************** From: Tucker Taft Sent: Friday, May 6, 2011 7:34 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. > > As a pragma, we wouldn't even need to move this to Annex J; it could > simply disappear. > > Probably the only real benefit of 13.11.3 is that it gets the term > "garbage collection" in the Standard and index, so that everyone can > find out that Ada doesn't have it. ;-) > > Anyway, it is pretty late to consider this, but since I haven't yet > done the work to "aspectize" it in the draft Standard, we still can > move the whole thing to Annex J or delete it outright if we want. > > So here's another straw poll: > > Please rank these options from 1 to 4, with 1 being the most preferred > and 4 being the least. > > __1_____ Remove 13.11.3 (Pragma Controlled) completely from the standard. > > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make > it an aspect. > > ___3____ Move the entire contents of 13.11.3 to Annex J, but still > make it an aspect. > > ___4____ Make pragma Controlled into an aspect, move just the pragma > to Annex J (the solution currently approved in AI05-0229-1). **************************************************************** From: Edmond Schonberg Sent: Friday, May 6, 2011 9:46 AM Get rid of it. ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard. ____2___ Move the entire contents of 13.11.3 to Annex J, do not make it an aspect. ___3____ Move the entire contents of 13.11.3 to Annex J, but still make it an aspect. ___4____ Make pragma Controlled into an aspect, move just the pragma to Annex J (the solution currently approved in AI05-0229-1). **************************************************************** From: Robert Dewar Sent: Friday, May 6, 2011 11:26 AM >> Please rank these options from 1 to 4, with 1 being the most >> preferred and 4 being the least. >> >> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard. >> >> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make >> it an aspect. >> >> ___3____ Move the entire contents of 13.11.3 to Annex J, but still >> make it an aspect. >> >> ____4___ Make pragma Controlled into an aspect, move just the pragma >> to Annex J (the solution currently approved in AI05-0229-1). >> > > I think pragma Controlled is actively harmful, I only saw it used by > people who did not understand its (none) effect, and who were > expecting from it properties that it did not ensure. OK, I find that a convincing argument, I change my vote to agree with the above **************************************************************** From: Steve Baird Sent: Friday, May 6, 2011 12:56 PM Edmond Schonberg wrote: > Get rid of it. Agreed. My vote is identical to Bob's, below. Bob Duff wrote: > My vote is identical to Randy's, above. [Editor's note: the above is the unedited message. Any infinite recursion is the responsibility of the original author. ;-)] **************************************************************** From: Gary Dismukes Sent: Friday, May 6, 2011 1:20 PM I'm also fine with jettisoning it, and my vote matches others. Looks like we have a true consensus. **************************************************************** From: Brad Moore Sent: Friday, May 6, 2011 7:03 PM My vote is identical to Randy's and the others **************************************************************** From: Bob Duff Sent: Wednesday, May 11, 2011 11:54 AM AI05-0229-1, Specifiable aspects says: ===pragma Interrupt_Priority, Priority (the pragmas are to be obsolescent) [Editor's Note: I'd much prefer that there was only one aspect here, probably named "Base_Priority", but the rules about converting to subtype Any_Priority vs. to subtype Priority at evaluation time force two aspects. That's because these aspects are expressions that are evaluated when the task (or protected) object is elaborated, not values evaluated at the freezing point. Personally, I'd drop the two subtypes, but one presumes that there is some value to the bifrucation and in any case it is 30 years too late for that.] ^^^^^^^^ Less than 20 years -- Interrupt_Priority was added in Ada 95. The split was discussed heavily at the time, and everybody seemed to agree that it's a good idea to flag interrupt priorities in a special way. You don't want to allow "pragma Priority(99)" if 99 just happens to be an interrupt level. **************************************************************** From: Robert Dewar Sent: Wednesday, May 11, 2011 11:54 AM Right, I agree with that decision and disagree with Randy. Btw, this silly (IMO) business of moving these pragmas to obsolescent status is harmless (except for creating extra work) unless they are included in No_Obsolescent_Features, in which case we have an unacceptable incompatibility on our hands. **************************************************************** From: Bob Duff Sent: Thursday, May 12, 2011 8:31 AM I was rather uncomfortable with this change. I don't remember, but I probably voted against it, or abstained. It is implementation defined whether No_Obsolescent_Features gripes about these pragmas. A gratuitous non-portability, IMHO, but relatively harmless. **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 8:39 AM Definitely gratuitous, but also irrelevant, for now implementation defined these days mostly means "defined by GNAT" when it comes to Ada 2012. I suggest we NOT include these changes in No_Obsolescent_Features for GNAT, there is no point whatever in making an incompatible change. Is there really some other Ada 2012 compiler that strongly wants a different definition? If not, why not just define it the way it is going to be, rather than leave this unnecessary non-portability around. To me, we have warnings on unrecognized pragmas in any case in all compilers, so there is really no need for this to be included in NOF. If a compiler was so stupid as to remove these pragmas in the future, or if the ARG was so stupid as to remove them, then the compiler would warn. To me obsolescent in practice means "defined, required, and will always be required, but someone thinks it is a pity that this is the case" :-) :-). The whole business of Annex J is gratuitous IMO. **************************************************************** From: Bob Duff Sent: Thursday, May 12, 2011 8:45 AM > I suggest we NOT include these changes in No_Obsolescent_Features for > GNAT, ... I was in charge of implementing AI05-0229-1 in GNAT, and that's exactly the decision I made yesterday: I closed the ticket without modifying the behavior of No_Obsolescent_Features. The other part of AI05-0229-1 was to make lots of pragmas and attributes into "aspects", which you (Robert) had already mostly done, and I added the rest. **************************************************************** From: Randy Brukardt Sent: Thursday, May 12, 2011 1:07 PM ... > It is implementation defined whether No_Obsolescent_Features gripes > about these pragmas. A gratuitous non-portability, IMHO, but > relatively harmless. That was done because that was the way that the previous exceptions from the restriction are handled. As a practical matter, everything in the annex should be rejected when this restriction exists. We're giving a permission to vary from that in a few specific cases, but no user should really be depending upon that permission being used. The entire point of the restriction is to allow people to ensure that they aren't using old junk in new code; that clearly includes this set of pragmas. The exception exists only because people currently using this restriction might be impacted. Really, this restriction (along with a number of other things) should work differently depending on what language you are trying to enforce. And in this case, what is restricted really should depend on whether the user wants to restrict Ada 2005 Annex J (in existing code) or Ada 2012 Annex J (in new code) -- and that's separate from which language version is being used to compile the code. That clearly requires separate restrictions, something the language cannot provide (sadly) because we're not allowed to talk about previous versions in the Standard. **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 1:40 PM > ... >> It is implementation defined whether No_Obsolescent_Features gripes >> about these pragmas. A gratuitous non-portability, IMHO, but >> relatively harmless. > > That was done because that was the way that the previous exceptions > from the restriction are handled. As a practical matter, everything in > the annex should be rejected when this restriction exists. We're > giving a permission to vary from that in a few specific cases, but no > user should really be depending upon that permission being used. Well I don't see why not. This is implementation defined, so Annex M is clear on the actual effect. For the vast majority (not all, but most) of our users, being compatible with other Ada compilers is not an issue, so there is no reason for them to follow Randy's advice here. The trouble is that if you make NOF reject all obsolescent features, it is useless (due to some very injudicious IMO inclusions in annex J). > The entire point of the restriction is to allow people to ensure that > they aren't using old junk in new code; that clearly includes this set > of pragmas. The exception exists only because people currently using > this restriction might be impacted. No, it also exists because a reasonable coding style is to reject most of the Annex J stuff, but not everything. Actually to be fair I find the restriction pretty useless, given it rejects the use of package ASCII. It's plain horrible to have to with the ISO package, especially if you don't allow USE clauses. In practice in GNAT we have a parallel mechanism -gnatwj, warn on obsolescent features. the documentation says: > In addition to the above cases, warnings are also generated for GNAT > features that have been provided in past versions but which have been > superseded (typically by features in the new Ada standard). > For example, @code{pragma Ravenscar} will be flagged since its > function is replaced by @code{pragma Profile(Ravenscar)}. > > Note that this warning option functions differently from the > restriction @code{No_Obsolescent_Features} in two respects. > First, the restriction applies only to annex J features. > Second, the restriction does flag uses of package @code{ASCII}. So actually I don't care that much if the pragmas are included, but including the pragmas will surely make the restriction even more hopelessly unusable :-) > Really, this restriction (along with a number of other things) should > work differently depending on what language you are trying to enforce. > And in this case, what is restricted really should depend on whether > the user wants to restrict Ada 2005 Annex J (in existing code) or Ada > 2012 Annex J (in new > code) -- and that's separate from which language version is being used > to compile the code. That clearly requires separate restrictions, > something the language cannot provide (sadly) because we're not > allowed to talk about previous versions in the Standard. As I say, the issue to me is what it is sensible to include. I would find a compiler that followed randy's advice to be plain annoying. Nothing to do with compatibility issues. **************************************************************** From: Randy Brukardt Sent: Thursday, May 12, 2011 2:12 PM ... > As I say, the issue to me is what it is sensible to include. > I would find a compiler that followed randy's advice to be plain > annoying. > Nothing to do with compatibility issues. Nothing new here. You've said this before (that you would find a compiler that operates like I think a compiler should is annoying). Hopefully, you'll never need to use Janus/Ada. ;-) **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 2:19 PM Well actually, for us -gnatwj is much more what you want than the restriction. I have never understood why people would want to say with Ada.Characters.Latin_1 ... Put (Ada.Characters.Latin_1.LF); instead of the so much more convenient Put (ASCII.LF); SO I would never use the restriction anyway, so I don't really care what it does :-) The trouble is that it *sounds* reasonable to people to avoid obsolescent features, so it is all to easy for a requirement of using the restriction to creep into coding standards documents. If such a requirement made people do major surgery on their programs to remove all the pragmas and replace by aspects, that would constitute in effect a huge extra barrier to the use of Ada 2012. **************************************************************** From: Randy Brukardt Sent: Thursday, May 12, 2011 2:38 PM ... > The trouble is that it *sounds* reasonable to people to avoid > obsolescent features, so it is all to easy for a requirement of using > the restriction to creep into coding standards documents. I agree with this, but trying to keep "coding standards" reasonable falls outside of the perview of the ARG. > If such a requirement made people do major surgery on their programs > to remove all the pragmas and replace by aspects, that would > constitute in effect a huge extra barrier to the use of Ada 2012. Right, which is why I said that you need different restrictions for existing code and for new code. Indeed, applying restrictions to existing code is silly (I hope no coding standards are doing that), because it means a lot of rework for no reason. One could imagine a No_Ada_2005_Obsolescent_Features restriction for the purpose of existing systems, but that's outside of what the Standard can do. This is a major problem with most restrictions anyway (given that they apply to the entire partition whether you want that or not). Restrictions that are mostly style-related (like this one) should only apply to the current unit (it only makes sense to use them in new code). But only the portability ones (No_Implementation_Pragmas, etc.) get this right. Sigh. **************************************************************** From: Bob Duff Sent: Thursday, May 12, 2011 2:40 PM Just a general comment on restrictions: I can't get too excited about the exact meaning of particular restrictions. If the restriction is too restrictive, don't use it. If you want a restriction that's different from existing ones, ask your vendor to provide one. Pragma Restrictions is one of my favorite features, precisely because it allows to much freedom to choose what you want for your own project. **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 2:42 PM > ... >> The trouble is that it *sounds* reasonable to people to avoid >> obsolescent features, so it is all to easy for a requirement of using >> the restriction to creep into coding standards documents. > > I agree with this, but trying to keep "coding standards" reasonable > falls outside of the perview of the ARG. Not in my opinion, creating annex J had consequences, and it is up to us to anticipate and deal with these consequences. >> If such a requirement made people do major surgery on their programs >> to remove all the pragmas and replace by aspects, that would >> constitute in effect a huge extra barrier to the use of Ada 2012. > > Right, which is why I said that you need different restrictions for > existing code and for new code. Indeed, applying restrictions to > existing code is silly (I hope no coding standards are doing that), > because it means a lot of rework for no reason. One could imagine a > No_Ada_2005_Obsolescent_Features restriction for the purpose of > existing systems, but that's outside of what the Standard can do. People apply coding standards to existing code all the time. Remember that 178B requires you have a comprehebsive coding standard. **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 2:52 PM > Just a general comment on restrictions: I can't get too excited about > the exact meaning of particular restrictions. If the restriction is > too restrictive, don't use it. If you want a restriction that's > different from existing ones, ask your vendor to provide one. I think you probably miss my point. You are assuming that the programmers choose the set of restrictions. That's not typically the case. Coding standards for 178B purposes are typically decided by a separate team who is not as sensible as the Duff that wrote the above. > Pragma Restrictions is one of my favorite features, precisely because > it allows to much freedom to choose what you want for your own > project. You is simple in our world, not so simple in the real world **************************************************************** From: Bob Duff Sent: Thursday, May 12, 2011 3:21 PM > I think you probably miss my point. Not really. My point is that it's not us Ada language designers placing restrictions on people. It's a programmer. Or a project manager. Or a committee of beaurocrats. Whatever. And that's the beauty of pragma Restrictions. We don't need to decide whether (say) heap allocation is good or evil. In fact, it's evil in some programs, but not others. So we can provide No_Heap_Alloc, and let people choose whether to use it. The fact that some folks will choose unwisely is not something I can do anything about. I'm well aware that idiotic coding conventions exist in the real world. But I can't fix that fact, so I don't worry about it. **************************************************************** From: Robert Dewar Sent: Thursday, May 12, 2011 3:34 PM But you should have worried about it when you created annex J. It was an inevitable and undesirable result of creating this annex that these annoying coding standards exist. You can't take actions without thought as to the real world consequences, we really can't afford to be THAT far embedded in the ivory tower. The restrictions we choose shape the way people will write coding standards! **************************************************************** From: Bob Duff Sent: Thursday, May 12, 2011 3:46 PM > But you should have worried about it when you created annex J. Annex J didn't turn out the way I intended. And I think I've told you more than once: I have (since Ada 9X days) come around to your point of view -- we'd be better off without any Annex J. Also note that I didn't really support moving all those pragmas into Annex J. **************************************************************** !topic Moving pragmas to Annex J (AI05-229) !reference J.15.3, J.15.5 !from Adam Beneschan 11-06-22 !discussion I realize I'm a little late to this party; I haven't been able to keep up with all the proposed language changes, and I wasn't aware of this AI until just now. I apologize for not making these comments sooner. I have some concerns about moving some of these pragmas to Annex J. I realize that it will still be legal to use them; however, putting them in a section called "obsolescent features" appears to give them "second-class" status, with the implication that their use is discouraged. (J(1) actually says "not recommended".) And I think in at least a couple cases, it's a mistake to give them that sort of status. The cases I'm concerned about are Inline and Import (probably also Export and Convention). When writing the specification of a package P, I've seen lots of cases where a subprogram is defined in the visible part of the package, and Inline appears in the private part. Although I don't think it affects the semantics in any way of a package that with's P, from a coding style standpoint I think it's a good idea to allow Inline in the private part. The visible part should describe the characteristics of the package and its subprograms that the writer of a WITH'ing package would need to know about. The fact that the subprogram is inlined is (in most cases) an implementation detail that is not important to the user of P. "Requiring" this implementation detail to appear in the visible part would clutter up the definition. I'd think that moving this sort of implementation detail to the private part wherever possible ought to be encouraged, or at least not discouraged; but moving it to Annex J does discourage this, which I think is wrong. Similar comments apply to the Import pragma. If a subprogram appears in the specification of P, but the implementor of P decides to implement it by importing it directly from a C library, that's an implementation detail that doesn't really belong in the visible part. In this case, the clutter seems worse because it will take three aspects (Import, Convention, External_Name) to specify the needed information. There's a more serious problem with Import that I realized after I started writing this: if the External_Name or Link_Name involves a named string constant, using aspect clauses instead of Import will require this constant to be made visible, which might be undesirable. Example: package Interface_To_Some_C_Library is ... procedure Gyre (X : in out Slithy_Tove); procedure Gimble (X : in out Slithy_Tove); function Is_Mimsy (Obj : Borogove) return Boolean; private Prefix : constant String := "lc12_"; pragma Import (C, Gyre, Prefix & "gyre"); pragma Import (C, Gimble, Prefix & "gimble"); pragma Import (C, Is_Mimsy, Prefix & "mimsy"); end Interface_To_Some_C_Library; Using aspect clauses in this case would require moving the Prefix constant to the visible part of the package. It should not be "required" to do this (or, more accurately, putting Prefix in the private part, which is certainly where it belongs, shouldn't be considered "not recommended"). I haven't looked through the AI to see if there are other cases of pragmas being moved to Annex J that could have the same problem (i.e. causing implementation details that ought to be specifiable in a private part to be moved to the visible part). **************************************************************** From: Randy Brukardt Sent: Wednesday, June 22, 2011 5:44 PM I don't believe that either Inline or Import should be hidden in the private part, because both have (subtle) semantic effects that potentially break privacy. In particular, inline adds dependencies that might make linking a program impossible. (I don't think inline should be allowed to do that, either, but that's the way it is.) Import usually requires parameters that also have convention C -- it's rarely possible to hide the *entire* thing. It's better to hide Import and all of the convention C stuff in a private package, and have the body of the Ada package call those routines (they can then fix up the Ada semantics at the same time). In that case, the private package is a C interface from the beginning and there is no reason to even think about hiding these things. It's unlikely that (especially if you want this to work with many Ada compilers, not just a specific one, because the only way to guarantee C-compatibility is with convention C) you can make calls directly without exposing the C-ness. Finally, the pragma syntax and semantics is *awful* for subprograms (remember all the renaming games that need to be played to make these work if there is any overloading), and the sooner people stop using them the better. If we *really* believe this is a real problem, we ought to find a way to allow aspects in the private part for subprograms (probably by allowing a repeated declaration with the "hidden" aspects). In any case, people can and will use the obsolescent pragmas. The same is true for attribute_definition_clauses (which we're not obsolescing because there are a few uses that cannot be done with aspects), but for most aspects (like size) you are better using aspects instead. (I've never believed in putting size clauses in the private part; that was the cause of many Ada language and Ada compiler bugs and never should have been allowed in the first place. We could have much simpler freezing rules if this sort of thing wasn't allowed.) **************************************************************** From: Randy Brukardt Sent: Wednesday, July 6, 2011 6:11 PM Christoph Grein notes that the lists of 13.1(8.f-kk) contains a number of obsolescent pragmas. This list gives type-related representation items, subtype-related ones, and ones that are neither. Replacing these pragmas with aspects directly won't work, because while pragmas are representation items, an aspect_specification is not a representation item (although it mught be used to specify a aspect of representation -- go figure). The choices seem to be: (1) Do nothing. The pragmas might be obsolescent, but they surely are still representation items and still make sense in this list. (2) Change the list headers to talk about aspects of representation rather than the actual items. That would require dropping "pragma" and "clause" throughout the lists. This would be the most correct and useful, but also is the most churn. At least this is an AARM note so not much documentation of the changes is needed. (3) Just change "pragma" to "aspect" here and be happy. But that seems to confuse aspects with the means of setting them. (4) Somehow change "representation item" to include aspect_specifications that set representation aspects, and then change "pragma" to "aspect" as needed. This might actually be the best solution, since not calling such things "representation items" seems unusual. But we've been living with that for a long time now, and I don't think we need such a change elsewhere. Since that would be a normative change, it would have the most risk. (5) Delete this silly list (it is a pain to maintain, and it is of dubious utility -- especially given the new aspect index). I'm leaning toward (1), but that probably is in part because it is the least work for me. (2) would probably be the most accurate and least confusing, but (5) also is appealing. Thoughts?? **************************************************************** From: Bob Duff Sent: Wednesday, July 6, 2011 6:30 PM > I'm leaning toward (1), but that probably is in part because it is the > least work for me. (2) would probably be the most accurate and least > confusing, but (5) also is appealing. I more-or-less agree. I lean toward (1). I think this AARM junk is my handiwork, but I wouldn't mind (5) too much -- just get rid of it if it's causing trouble. **************************************************************** From: Tucker Taft Sent: Wednesday, July 6, 2011 6:31 PM 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)". **************************************************************** !topic Language Defined Aspects !reference Ada 2012 RM L !from Christoph Grein 2011-07-14 !keywords pragma aspect !discussion We have Annex L Language Defined Pragmas. Since aspects now replace many pragmas, shouldn't that now be Annex L Language Defined Aspects and Pragmas? It's difficult to see which aspects are allowed for a given declaration. For instance, which aspects are allowed on generic_instantiation? This annex should help solve this problem. **************************************************************** From: Randy Brukardt Sent: Monday, July 18, 2011 8:00 PM ... > We have Annex L Language Defined Pragmas. > > Since aspects now replace many pragmas, shouldn't that now be Annex L > Language Defined Aspects and Pragmas? No. > It's difficult to see which aspects are allowed for a given declaration. > For instance, which aspects are allowed on generic_instantiation? This > annex should help solve this problem. Right idea, wrong annex, and the need was long since realized by the ARG (see AI05-0229-1 for details). The contents of the annex were written months ago by Bob Duff. As noted in the page describing this draft, not all of the contents of AI05-0212-1 or AI05-0229-1 made it into draft 12. I just haven't put that annex into the standard as it will require significant programming effort for the formatter tool (and substantial work placing the individual commands into the RM source files) and it seemed that it was a better use of my limited time to get the majority of the normative text into draft 12 rather than spending most of the time on a non-normative annex. **************************************************************** 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 3.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, 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. **************************************************************** From: Tucker Taft Sent: Monday, September 12, 2011 10:30 AM [From Tucker's editorial review:] 13.3 65.a/3: To be honest: This definition somewhat conflicts with the "automatic" one for the obsolescent attribute Storage_Size (which can be specified). We intend for the above definition to supercede that "automatic" definition for this attribute. This is bizarre. I highly recommend we drop Storage_Size from the obsolescent annex, as these two features now conflict badly. It should no longer be possible to specify Storage_Size with an attribute definition clause, or if it is, it should be *exactly* equivalent to specifying the aspect with an aspect specification clause. J.9 The Storage_Size attribute As mentioned above (13.3, 65.a/3), I believe this attribute should be removed from the language since we now have a specifiable aspect with the same name and a different meaning. **************************************************************** From: Randy Brukardt Sent: Friday, September 30, 2011 11:57 PM This *is* bizarre, but dropping the attribute specification would be highly incompatible. At least one Ada user I know really well (me) only uses this form because he hates the pragmas so much that he never implemented them. Dropping this attribute_definition_clause would break all of my programs (including Claw). I doubt I'm the only one. And forcing the semantics to work like the old pragma and the new aspect isn't practical -- the aspect specifies an *expression*, that is evaluated per-object, while an attribute_definition_clause specifies a *value*, that is evaluated at the place of the clause (and thus is evaluated once per-type -- that was the original reason for introducing the pragma). Besides requiring a new mechanism that would only be used for this one attribute, it also would introduce an inconsistency (evaluating the expression multiple times in different places might get different answers than the current evaluation rules, potentially causing significant headaches). The bizarre behavior seemed like the least evil of the options; it doesn't break any existing code, and just requires that the implementer treat the obsolescent attribute separately from the aspect. That doesn't seem too hard to do. There might be a way to unify these without breaking everything, if we could somehow make the attribute_definition_clause provide an expression that is the evaluated value of the attribute. (That is, the evaluation would occur at the point of the attribute_definition_clause, then that value would become the expression that the aspect evaluates per-object - which obviously would have not effect.) I don't have any idea how to accomplish that; they would have to be some weird wording somewhere that existed only for the obsolescent attribute. If you want to take a stab at it, please feel free (but it just makes my head hurt :-). > J.9 The Storage_Size attribute > > As mentioned above (13.3, 65.a/3), I believe this attribute should be > removed from the language since we now have a specifiable aspect with > the same name and a different meaning. See above. **************************************************************** From: Tucker Taft Sent: Saturday, October 1, 2011 7:53 AM ... > This *is* bizarre, but dropping the attribute specification would be > highly incompatible. At least one Ada user I know really well (me) > only uses this form because he hates the pragmas so much that he never implemented them. > Dropping this attribute_definition_clause would break all of my > programs (including Claw). I doubt I'm the only one. Do you ever use variables in your attribute specifications, or are they always literals or constants? > And forcing the semantics to work like the old pragma and the new > aspect isn't practical -- the aspect specifies an *expression*, that > is evaluated per-object, while an attribute_definition_clause > specifies a *value*, that is evaluated at the place of the clause (and > thus is evaluated once per-type > -- that was the original reason for introducing the pragma). Besides > requiring a new mechanism that would only be used for this one > attribute, it also would introduce an inconsistency (evaluating the > expression multiple times in different places might get different > answers than the current evaluation rules, potentially causing significant headaches). I see no problem if we require that the attribute specification use only constants or literals. Then we equate it with the aspect specification, and we know it evaluates to the same value everywhere. > The bizarre behavior seemed like the least evil of the options; it > doesn't break any existing code, and just requires that the > implementer treat the obsolescent attribute separately from the > aspect. That doesn't seem too hard to do. I don't agree with that. I think it is a mess as it is now. People will have a hard enough time with the new "aspect" concepts, and it will really help if, when thinking about attributes, they are interchangeable. If somehow specifying Storage_Size with an attribute definition clause is significantly different than specifying it with an aspect clause, the poor user will really be confused, and almost certainly implementors will mess it up one way or the other. > There might be a way to unify these without breaking everything, if we > could somehow make the attribute_definition_clause provide an > expression that is the evaluated value of the attribute. (That is, the > evaluation would occur at the point of the > attribute_definition_clause, then that value would become the > expression that the aspect evaluates per-object - which obviously > would have not effect.) I don't have any idea how to accomplish that; > they would have to be some weird wording somewhere that existed only > for the obsolescent attribute. If you want to take a stab at it, please feel free > (but it just makes my head hurt :-). I think we could require the expression given in the Storage_Size attribute definition clause to involve only constants and literals. We say something similar about address clauses for objects, I believe. **************************************************************** From: Randy Brukardt Sent: Monday, October 10, 2011 8:56 PM ... > Do you ever use variables in your attribute specifications, or are > they always literals or constants? I think they're usually constants. But that's irrelevant (see below). > > And forcing the semantics to work like the old pragma and the new > > aspect isn't practical -- the aspect specifies an *expression*, that > > is evaluated per-object, while an attribute_definition_clause > > specifies a *value*, that is evaluated at the place of the clause > > (and thus is evaluated once per-type > > -- that was the original reason for introducing the pragma). Besides > > requiring a new mechanism that would only be used for this one > > attribute, it also would introduce an inconsistency (evaluating the > > expression multiple times in different places might get different > > answers than the current evaluation rules, potentially causing > > significant headaches). > > I see no problem if we require that the attribute specification use > only constants or literals. Then we equate it with the aspect > specification, and we know it evaluates to the same value everywhere. I know of nothing like this anywhere else in the Ada standard. We have rules that require static expressions, but that would prevent using the storage size of some other task (T'Storage_Size) -- which would be incompatible again. And creating a rule just for this case seems silly. > > The bizarre behavior seemed like the least evil of the options; it > > doesn't break any existing code, and just requires that the > > implementer treat the obsolescent attribute separately from the > > aspect. That doesn't seem too hard to do. > > I don't agree with that. I think it is a mess as it is now. > People will have a hard enough time with the new "aspect" > concepts, and it will really help if, when thinking about attributes, > they are interchangeable. > If somehow specifying Storage_Size with an attribute definition clause > is significantly different than specifying it with an aspect clause, > the poor user will really be confused, and almost certainly > implementors will mess it up one way or the other. But this is wrong: the attributes and aspects are subtly different, and that has nothing to do with this attribute. The point at which the expressions are resolved and evaluated differ for all aspect_specifications vs. attribute_definition_clauses, and that can change the behavior even for supposedly simple aspects like Size. We discussed that extensively in the past. The same is true here. It *appears* to be more significant, but would be only in pathological programs. After all, no per-object expressions can appear in the attribute_definition_clause, and including function calls or variables that change values when evaluated is just plain weird. So, in practice, the result will be the same either way. As far as implementations go, the implementation of aspect_specifications and attribute_definition_clauses is similar, but the implementer has to be very careful about resolution and evaluation points. I expect everybody will make mistakes in this area -- but that has nothing whatsoever to do with Storage_Size; it applies to every aspect that can also be specified by an attribute. (Recall that Robert said that implementing aspect_specifications correctly was a lot of work, there is a lot less reuse possible than appears on the surface.) > > There might be a way to unify these without breaking everything, if > > we could somehow make the attribute_definition_clause provide an > > expression that is the evaluated value of the attribute. (That is, > > the evaluation would occur at the point of the > > attribute_definition_clause, then that value would become the > > expression that the aspect evaluates per-object - which obviously > > would have not effect.) I don't have any idea how to accomplish > > that; they would have to be some weird wording somewhere that > > existed only for the obsolescent attribute. If you want to take a > > stab at it, please feel free (but it just makes my head hurt :-). > > I think we could require the expression given in the Storage_Size > attribute definition clause to involve only constants and literals. > We say something similar about address clauses for objects, I believe. As previously noted, that is unique (I don't see anything like this for address clauses, not even in the recommended-level-of-support). Requiring the expression to be static would work (sort of), but would have some real-world incompatibilities. And that does absolutely nothing to eliminate the weirdness, indeed it makes it worse, because the aspect has no such limitations. (Remember that the weirdness is that that this attribute is not related to the aspect of the same name, at least in the sense that there is no "automatic" aspect for this attribute). The only thing that would fix that is eliminating the attribute altogether, which would be too incompatible to contemplate. So I honestly don't see the point; no user or implementer will be surprised by the semantics (at least after a bit of reflection - no one expects or wants attribute_definition_clauses to do per-object evaluation). And this is an *obsolescent* attribute; we really don't want to spend any effort on those at all. The only thing I would even consider changing is whether there ought to be an RM sentence in J.9 to make it crystal clear that the expression is evaluated here (and is not per-object). [There already is an AARM note to that effect.] Perhaps add something like: Redundant[This specifies the Storage_Size aspect to have the value of the expression.] It would make the relationship between the attribute and aspect a bit clearer, too. **************************************************************** From: Tucker Taft Sent: Monday, October 10, 2011 9:32 PM >> I see no problem if we require that the attribute specification use >> only constants or literals. Then we equate it with the aspect >> specification, and we know it evaluates to the same value everywhere. > > I know of nothing like this anywhere else in the Ada standard. We have > rules that require static expressions, but that would prevent using > the storage size of some other task (T'Storage_Size) -- which would be > incompatible again. And creating a rule just for this case seems silly. This limitation is described in 13.1(22-22.h): 22 An implementation need not support representation items containing nonstatic expressions, except that an implementation should support a representation item for a given entity if each nonstatic expression in the representation item is a name that statically denotes a constant declared before the entity. 22.a Reason: This is to avoid the following sort of thing: 22.b X : Integer := F(...); Y : Address := G(...); for X'Address use Y; 22.c In the above, we have to evaluate the initialization expression for X before we know where to put the result. This seems like an unreasonable implementation burden. 22.d The above code should instead be written like this: 22.e Y : constant Address := G(...); X : Integer := F(...); for X'Address use Y; 22.f This allows the expression “Y” to be safely evaluated before X is created. 22.g The constant could be a formal parameter of mode in. 22.h An implementation can support other nonstatic expressions if it wants to. Expressions of type Address are hardly ever static, but their value might be known at compile time anyway in many cases. >>> The bizarre behavior seemed like the least evil of the options; it >>> doesn't break any existing code, and just requires that the >>> implementer treat the obsolescent attribute separately from the >>> aspect. That doesn't seem too hard to do. >> >> I don't agree with that. I think it is a mess as it is now. >> People will have a hard enough time with the new "aspect" >> concepts, and it will really help if, when thinking about attributes, >> they are interchangeable. >> If somehow specifying Storage_Size with an attribute definition >> clause is significantly different than specifying it with an aspect >> clause, the poor user will really be confused, and almost certainly >> implementors will mess it up one way or the other. > > But this is wrong: the attributes and aspects are subtly different, > and that has nothing to do with this attribute. The point at which the > expressions are resolved and evaluated differ for all aspect_specifications vs. > attribute_definition_clauses, and that can change the behavior even > for supposedly simple aspects like Size. We discussed that extensively > in the past. I guess I don't remember this issue as well as you do. > The same is true here. It *appears* to be more significant, but would > be only in pathological programs. After all, no per-object expressions > can appear in the attribute_definition_clause, and including function > calls or variables that change values when evaluated is just plain > weird. So, in practice, the result will be the same either way.... I agree this is not worth making a big fuss over. **************************************************************** From: Tucker Taft Sent: Monday, October 10, 2011 9:52 PM > An implementation need not support representation items containing > nonstatic expressions, except that an implementation should support a > representation item for a given entity if each nonstatic expression in > the representation item is a name that statically denotes a constant declared > before the entity. ... For what it is worth, I know AdaMagic, and I believe GNAT, take advantage of 13.1(22) and disallow non-static expressions in Address clauses that don't satisfy this requirement. **************************************************************** From: Randy Brukardt Sent: Monday, October 10, 2011 10:21 PM OK, but two points: (1) That's Recommended Level of Support, so it's optional. What you were suggesting] (if I understood it) was a requirement on all implementations -- and that's different. It would need a more precise definition, and in any case we couldn't use this one. (2) This already applies to the Storage_Size attribute; an implementation could already make such a requirement if it wanted to. So there doesn't seem to be any need for the language to do so. Bonus point: The above doesn't seem to allow the use of T'Size or T'Storage_Size in a representation item, even when the value of the attribute [aspect] was specified as a static expression. That's because the value of an attribute (aspect) isn't a "constant" (which has a formal definition - a constant has to be an object, and an attribute is not an object). That would be annoying; I suspect that in practice such things are allowed even if this permission is being used. (Janus/Ada has both the concepts of "static" and of "compile-time"; the former being a subset of the latter -- we use "compile-time" everywhere other than places where language rules require "static".) **************************************************************** From: Erhard Ploedereder Sent: Saturday, October 1, 2011 5:54 PM C.3.1. 6.3/3 reads: The value of aspect Attach_Handler is an expression, which shall be of type Interrupts.Interrupt_Id. This aspect is never inherited. The old version read: > For the Attach_Handler pragma, the expected type for the expression is > Interrupts.Interrupt_Id (see C.3.2). Comment 1: "the value is an expression" is not the usual way of expressing things, or it it? The value can only be the result of the expression. Comment 2: Why not simply: For the Attach_Handler aspect, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2). Comment 3: drop the ",". It is not a descriptive "which", but a restricting one, which is supposed to have no ",". **************************************************************** From: Randy Brukardt Sent: Monday, October 10, 2011 8:17 PM I put the "Important" tag on this item because this wording is very common for aspects and if a change is necessary it is going to be very widespread in the Standard. For example, similar wording occurs for Storage_Size (13.3(65.2/3) and Priority (D.1(6.2/3)), along with many, many others. The statement has two purposes: (1) To specify that the value of the aspect is an expression (as opposed to a value). This is important, as it determines where the expression is evaluated (if a value, at the point of the freezing of the entity; if an expression, at some other point specifically defined). We want the "default" to be a value evaluated at the freezing point, so we don't need extra wording to deal with common cases like Size or Alignment or Pack. OTOH, we need the capability for later evaluation, for cases like preconditions and priority (per-object). The wording has to make it clear which is in fact used. 13.3.1(7/3 and 19/3) show this bifurcation. (2) To define the type of the expression used in the aspect. This is required by 13.3.1(7/3). So to answer your three comments: [1] No, this is not the usual way of putting this, because this is not the usual case. The (value of the aspect) is an expression (as opposed to a value, as for Size). [2] That would not say that the value of the aspect is an expression. (That is, that this is an expression-valued aspect.) [3] These are two virtually unrelated statements sharing only "expression"; there has to be some separator. I note that Preconditions and Type_Invariants use a much, much wordier version of this text, mainly because we needed to define a name for the expression. And they use separate paragraphs for the type and for the "aspect is specified by an expression". I originally used longer wording in this spirit, and Bob Duff objected that the result was very wordy without saying much. I think he proposed some form of the simpler wording that we currently have. Anyway, the fact that I've already simplified this wording for Bob leaves me unsure what to do. The *correct* thing to do would be to write all of this wording similarly to Preconditions, which would result in something like: Attach_Handler This aspect statically attaches an interrupt handler; it shall be specified by an expression. This aspect is never inherited. Name Resolution Rules For the Attach_Handler aspect, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2). This is very wordy, and has the additional problem of needing to create a short description of the aspect to "flow" into the text; those would have to be reviewed by the group (I *will* make mistakes in doing more than a dozen such aspects). In addition, I don't think this wording really makes clear that it is the expression itself and not the value of the expression that is the value of the aspect. You can usually figure that out by reading *all* of the semantics (since they typically will describe where the expression is evaluated if it is an expression; if that's not mentioned, then it probably is a value), but that doesn't seem to be the best way to do it. So I don't know of any improvement here that makes sense. It should be noted that 13.3.1 does a lousy job of separating these two cases as well, so there may be a fairly deep-rooted problem here. (One of wording, not of intent.) Suggestions are welcome. **************************************************************** From: Tucker Taft Sent: Monday, October 10, 2011 9:20 PM How about: The aspect Attach_Handler is an expression of type Interrupts.Interrupt_Id. This aspect is never inherited. I think it is confusing to use the term "value of aspect ... is an expression" and if we can avoid it, that would be a good thing. In 13.3.1 we simply say that an aspect *is* an expression or *is* a value. **************************************************************** From: Erhard Ploedereder Sent: Thursday, October 13, 2011 12:50 PM Let me suggest the following, which follows the words of 13.3.1 37/3 ("...unless the aspect itself is an expression") and 7/3 ("an aspect that is a value or an expression, the aspect_definition shall be an expression. The expected type for the expression is the type of the identified aspect of the associated entity;) : Turn the boilerplate that yields >The value of aspect Attach_Handler is an expression, which shall be of >type Interrupts.Interrupt_Id. Into: The aspect Attach_Handler is an expression, which shall be of type Interrupts.Interrupt_Id. and use the boilerplate wherever the aspect is indeed the expression that is to be evaluated at some later point, as in this case. (There are about 5 or 6 cases that fall into this category.) (Given the special semantics of "value = immediate evaluation, expression = delayed evaluation", that 13.3.1 introduces, it is terribly confusing to use both terms to explain a new aspect.) ------ Incidently, in 37/3, the second occurrence of expression (as cited above) is in the wrong font. It is not the syntactic notion of expression, but the semantic one, as in 7/3. **************************************************************** From: Randy Brukardt Sent: Wednesday, September 28, 2011 11:51 PM In Bob's review of 11.4.1, he writes: > 4/3 procedure Raise_Exception(E : in Exception_Id; > Message : in String := "") > with No_Return => True; "with No_Return => True" --> "with No_Return"? Why not take advantage of the shorthand? Seems more readable. -------------------- In Tucker's review of 13.1, he writes: 13.1 7.c/3, 14.e/3 (a total of 3 places): ... with Pack {=> True}; ... -------------------- It seems to me that if I follow both of these suggestions, I'll probably get more comments during the next review. :-) I admit that I wasn't very consistent about using the shorthand: I only used it for Pack. None of the other aspects seemed to read that well. (The primary trouble is "with"; but since no one has ever suggested an alternative that seemed any better -- even a new keyword -- we're pretty much stuck with that.) The aspects involved are at least Pack, No_Return, and Import. The latter is always followed by Convention, and it would (IMHO) look weird without the "=> True" -- like a positional parameter before a named one. The other two are no as clear-cut. (There may be others for which I did use the shortcut, it would be hard to check for those.) In any case, I'm not going to make any change here unless there is some sort of consensus as to whether or not to use the shorthand form in the Standard. So you guys argue it out between yourselves (I have plenty of other things to work on). **************************************************************** From: Tucker Taft Sent: Thursday, September 29, 2011 9:33 AM Some aspects read better than others in my view without the "=> True". To me, "with Pack" sounds weird, but "with No_Return" sounds reasonable. I agree we should be consistent for a particular aspect, but I don't see the need for us to use "=> True" always or never for all boolean aspects. And none of these are show-stoppers... **************************************************************** From: Randy Brukardt Sent: Thursday, September 29, 2011 5:07 PM > Some aspects read better than others > in my view without the "=> True". I agree so far... > To me, "with Pack" sounds weird, but > "with No_Return" sounds reasonable. ...but I feel exactly the reverse ("with Pack" seems fine, "with No_Return" seems weird). > I agree we should be consistent for > a particular aspect, but I don't see > the need for us to use "=> True" always or never for all boolean > aspects. > And none of these are show-stoppers... Right. Part of my thinking for Pack was that "with Pack" seems a bit weird, but "with Pack => True" seems worse. After all, if you write "True", it ought to make sense to write "False", and "with Pack => False" seems like complete nonsense to me. [We'll ignore for the moment that Pack itself is close to nonsense.] OTOH, "with No_Return => False" seems to make sense (although it is a double negative). Anyway, I think it matters what Bob and others think as well. (Right now, I'm leaning toward taking Bob's comment and ignoring yours, but I want to know what others think.) **************************************************************** From: Bob Duff Sent: Thursday, September 29, 2011 5:41 PM > > To me, "with Pack" sounds weird, but "with No_Return" sounds > > reasonable. > > ...but I feel exactly the reverse ("with Pack" seems fine, "with No_Return" > seems weird). I could go either way on both. > Anyway, I think it matters what Bob and others think as well. (Right > now, I'm leaning toward taking Bob's comment and ignoring yours, but I > want to know what others think.) I do not think it's important that the RM is consistent on this point. I think individual Ada projects will want to have a consistent style, but it's OK if the RM does not. Maybe it's even better to illustrate that both styles work. **************************************************************** From: Tucker Taft Sent: Thursday, September 29, 2011 5:54 PM For me, I expect a noun or a phrase after "with," never just a single verb. And "Pack" is a verb, while "No Return" is a noun phrase. So "with Pack" doesn't make sense to me grammatically, while "with No_Return" sounds just fine grammatically. "with Packing" would sound fine, but I agree with our earlier decision to use the pragma names, even if they are awkward alone after "with." I also don't understand your objection to "with Pack => False;" for what that's worth. I could easily imagine declaring type Bool_Vector is array(Positive range <>) of Boolean with Pack => False; to emphasize that unlike most vectors of Booleans, we do *not* want this one packed. This would be a warning to maintainers, presumably, that speed of access is more important than space considerations for this vector. And "with No_Return => False" seems downright weird to me, so we seem to have varying mileage on this one! **************************************************************** From: Robert Dewar Sent: Friday, September 30, 2011 3:55 AM > And "with No_Return => False" seems downright weird to me, so we seem > to have varying mileage on this one! which is a good thing, since it is the only reasonable justification for having two ways of doing things :-) :-) **************************************************************** From: John Barnes Sent: Friday, September 30, 2011 7:49 AM >> To me, "with Pack" sounds weird, but >> "with No_Return" sounds reasonable. > > ...but I feel exactly the reverse ("with Pack" seems fine, "with > No_Return" > seems weird). Obviously should be "with out Return" **************************************************************** From: Dan Eilers Sent: Friday, September 30, 2011 11:52 AM > > ...but I feel exactly the reverse ("with Pack" seems fine, "with > > No_Return" > > seems weird). > > Obviously should be "with out Return" and obviously, "with Pack" should be type A is packed array ... Maybe in Ada 2020 we will be back to Pascal. **************************************************************** From: Robert Dewar Sent: Saturday, October 1, 2011 9:01 AM > and obviously, "with Pack" should be > > type A is packed array ... I sort of hope a smiley is missing here, and that this is not a serious suggestion! **************************************************************** From: Dan Eilers Sent: Saturday, October 1, 2011 11:23 AM Why would you say that? Don't you think adjectives go well before nouns? Do you think we should say type T is record ... end record with tagged => true; type T is record ... end record with limited => true; type T is record ... end record with abstract => true; Ada 83 removed a lot of useful features from Pascal, including sets, subprogram pointers, in/out parameters on functions, packed as an array modifier, etc., and the trend ever since has been to gradually restore those features to the language. **************************************************************** From: Robert Dewar Sent: Saturday, October 1, 2011 5:48 PM > Don't you think adjectives go well before nouns? > Do you think we should say > type T is record ... end record with tagged => true; > type T is record ... end record with limited => true; > type T is record ... end record with abstract => true; We might have considered such if we had had aspects from the start, although my taste is that the above have verty different semantic force from packed. > Ada 83 removed a lot of useful features from Pascal, including sets, > subprogram pointers, in/out parameters on functions, packed as an > array modifier, etc., I find the last one in the list here oddly out of place, since it is just a syntactic issue, and for me I think the idea of having piles of keywords as modifers such as packed is simply horrible, so given that you are making this as a serious suggestion, I strongly object, and think it would be very undesirable to a) introduce a new keyword packed b) have three ways of saying an array is packed (bad enough having two!) ****************************************************************