!standard 13.2(5) 11-03-31 AI05-0229-1/07 !standard 13.11.3(5) !standard B.3.3(4) !standard E.4.1(8) !standard J.15(0) !standard K.1(0) !class Amendment 10-10-25 !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 fourth paragraph from the end of the Static Semantics in AI05-0183-1/09 (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.] 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. 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 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 if uses of the renamings of J.1 {and 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. 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(72), 13.3(72.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.6/2), and B.3(39.14/2). Delete B.3(34), B.3(39.7/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 => True;} [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 => True; [pragma No_Return(Raise_Exception);] [This is the only use of No_Return in an Ada predefined package.] ===pragma Controlled: (the pragma is to be obsolescent) Change the title of clause 13.11.3 to "Controlling Storage Reclamation". Modify 13.11.3(1/2): {Specifying aspect Controlled to have value True prevents}[Pragma Controlled is used to prevent] any automatic reclamation of storage (garbage collection) for the objects created by allocators of a given access type. Delete 13.11.3(2-4). [Now in Annex J.] Replace 13.11.3(5): For a non-derived access type, the following language-defined representation aspect may be specified: Controlled The type of aspect Controlled is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False. Modify 13.11.3(7): If {aspect Controlled is True}[a pragma Controlled is specified] for an access type with a standard storage pool, then garbage collection is not performed for objects in that pool. Modify 13.11.3(8): An implementation need not support garbage collection, in which case, {aspect Controlled}[a pragma Controlled] has no effect. ===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*. Modify B.3.3(29/2): An implementation may require that {aspect Controlled is True}[pragma Controlled be specified] for the type of an access subcomponent of an unchecked union type. ===pragma Discard_Names: [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.] ** Unchanged - TBD ** -- Assigned to Ed. ===pragma Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components: (the pragmas are to be obsolescent) C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. ===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 it applies to the value True. If the All_Calls_Remote aspect of a library unit is True, the library unit shall be a remote call interface. 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, indicates that 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). Other pragmas: ===pragma Preelaborable_Initialization (the pragma is to be obsolescent) Delete 10.2.1(4.1/2-4.2/2) [Now in Annex J.] In 10.2.1(10.1/3), replace ..., unless pragma Preelaborable_Initialization has been applied to the formal type; with ..., unless the Preelaborable_Initialization aspect is True for the formal type. Replace 10.2.1(11.1-11.8/2) with: [This includes corrections from AI05-0028-1 and AI05-0221-1.] The following rules specify which entities are said to be *eligible for preelaborable initialization*: * The partial view of a private type or private extension, a protected type without entry_declarations, a generic formal private type, or a generic formal derived type, is eligible for preelaborable initialization if and only if the Preelaborable_Initialization aspect is True for them. A protected type with entry_declarations or a task type is never eligible for preelaborable initialization. [Note: "Redundant" square brackets in preceding paragraph removed deliberately.] * A component (including a discriminant) of a record or protected type is eligible for preelaborable initialization if its declaration includes a default_expression whose execution does not perform any actions prohibited in preelaborable constructs as described above, or if its declaration does not include a default expression and its type is eligible for preelaborable initialization. * A derived type is eligible for preelaborable initialization if its parent type is eligible for preelaborable initialization and if the non-inherited components are all eligible for preelaborable initialization. However, a user-defined controlled type with an overriding Initialize procedure that is not a null procedure is not eligible for preelaborable initialization. * A view of a type is eligible for preelaborable initialization if it is an elementary type, an array type whose component type is eligible for preelaborable initialization, a record type whose components all are eligible for preelaborable initialization, or an interface type. For any type, the following language-defined type-related operational aspect is defined: Preelaborable_Initialization The type of aspect Preelaborable_Initialization is Boolean. If aspect Preelaborable_Initialization is True for a type, the type is said to have *preelaborable initialization*; conversely, if the aspect is False, the type does not have preelaborable initialization. [Editor's Note: This aspect has to be operational so we can specify it on partial views; that's not allowed for representation aspects.] For a composite type_declaration other than an incomplete_type_declaration and for a composite formal_type_declaration, this aspect may be specified. If not directly specified for a given type (including the case of derived type), the aspect is True if and only if the type is eligible for preelaborable initialization. If directly specified, the aspect_definition shall be a static expression. [redundant: The aspect is never inherited.] If the aspect Preelaborable_Initialization is True for a type, * the type shall be eligible for preelaborable initialization; and * the full view of the type (if any) shall be eligible for preelaborable initialization. If the aspect Preelaborable_Initialization is True for a generic formal type, then the corresponding actual type in an generic_instantiation shall have preelaborable initialization. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. AARM reason: The reason why the aspect may be specified for private types, private extensions, and protected types is fairly clear: the properties of the full view determine whether the type has preelaborable initialization or not; in order to preserve privacy we need a way to express on the partial view that the full view is well-behaved. The reason for supporting this for other composite types is more subtle: a non-null override for Initialize might occur in the private part, even for a nonprivate type; in order to preserve privacy, we need a way to express on a type declared in a visible part that the private part does not contain any nasty override of Initialize. AARM ramification: A value of True may not be specified for the Preelaborable_Initialization aspect of a protected types with one or more entry_declarations or of a task type. [Editor's note: The Static Semantics and Legality Rules are all mixed together here. We typically don't do that, but since we already did that in the past, it is left that way here.] In 10.2.1(15.a/3). replace "; the type still could have a pragma Preelaborable_Initialization given" with "; the Preelaborable_Initialization aspect of the type could still be True" [Editor's Note: This aspect can be specified on generic formal types. Thus the AI05-0183-1 statement that there are none is a lie. Gotta fix it.] Replace the penultimate paragraph in Static Semantics for AI05-0183-1/09 [13.3.1(32/3) in draft 11.5]: There are no language-defined aspects that may be specified on a renaming_declaration and only Preelaboration_Initialization (see 10.2.1) can be specified on a formal_type_declaration. ===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 type of aspect Interrupt_Handler is 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.] Replace C.3.1(10): The value of the Attach_Handler aspect identifies an interrupt. As part of the initialization of the associated object, if the Attach_Handler aspect is specified, the handler procedure is attached to the specified interrupt. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected. Modify C.3.1(11/2): If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which either {the}[an] Attach_Handler or Interrupt_Handler [pragma applies to]{aspect is specified for} one of its procedures, a check is made that the ceiling priority defined in the protected_definition is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. Modify C.3.1(12/1): When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If [an Attach_Handler pragma was used]{the Attach_Handler aspect was specified} and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored. Modify C.3.1(14/1/1): If the handlers for a given interrupt attached via [pragma]{aspect} Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via [pragma]{aspect} Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized. Modify C.3.1(17): When the [pragmas]{aspects} Attach_Handler or Interrupt_Handler [apply to]{are specified for} a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body. Modify C.3.1(19): Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler [pragmas]{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_definition), the following language-defined representation aspect may be specified: Storage_Size The value of 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). Should we make specifying the aspect for those illegal?? The inabilility to derive also means we cannot run afoul of 13.1(10).] Delete 13.3(62-65) [Now in Annex J.] 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 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. 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, 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_definition), protected type (including the anonymous type of a single_protected_definition), or subprogram, the following language-defined representation aspects may be specified: Priority The value of aspect Priority is an expression, which shall be of type Integer. Interrupt_Priority The value of 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 (a new possibility). Should we make specifying the aspects for those illegal?? The inabilility to derive also means we cannot run afoul of 13.1(10).] 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.7). 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_definition} is discussed in D.3. Modify D.1(17): The expression [in a Priority or Interrupt_Priority pragma that appears in a task_definition]{specified for the Priority or Interrupt_Priority aspect of a task} is evaluated for each task object (see 9.1). For [a]{the} Priority [pragma]{aspect}, the value of the expression is converted to the subtype Priority; for [an]{the} Interrupt_Priority [pragma]{aspect}, this value is converted to the subtype Any_Priority. The priority value is then associated with the task object whose [task_definition contains the pragma]{task declaration specifies the aspect}. Modify D.1(18): Likewise, the priority value is associated with the environment task if the {aspect is specified for}[pragma appears in the declarative_part of] the main subprogram. Change "pragma" to "aspect" in D.1(19). Modify D.3(6/2): The expression [in a Priority or Interrupt_Priority pragma task_definition]{specified for the Priority or Interrupt_Priority aspect} (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. If no Priority or Interrupt_Priority [pragma applies to]{aspect is specified for} a protected object, the initial priority is specified by the locking policy. Replace "pragma" by "aspect" in D.3(8/2). Modify D.3(10/2): If an Interrupt_Handler or Attach_Handler [pragma]{aspect} (see C.3.1) [appears in a protected_definition]{is specified for a protected subprogram of a protected type that does not have the Interrupt_Priority aspect specified}[ without an Interrupt_Priority pragma], the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority. Replace D.3(11/2): If neither aspect Priority nor Interrupt_Priority is specified for a protected type, and no protected subprogram of the type has aspect Interrupt_Handler or Attach_Handler specified, then the initial priority of the corresponding protected object is System.Priority'Last. ==pragma 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_definition) or subprogram, the following language-defined representation aspect may be specified: Relative_Deadline The value of 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.] [Editor's note: Task types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from task interfaces (a new possibility). Should we make specifying the aspects for those illegal?? The inabilility to derive also means we cannot run afoul of 13.1(10).] 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 there is no Relative_Deadline pragma then the initial absolute deadline of a task is the value of Default_Deadline. [Redundant: The environment task is also given an initial deadline by this rule.] [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_definition) or subprogram, the following language-defined representation aspect may be specified: CPU The value of 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 (a new possibility). Should we make specifying the aspects for those illegal?? The inabilility to derive also means we cannot run afoul of 13.1(10).] 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. 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. ** Unchanged - TBD ** -- Assigned to Tucker. ===pragmas Convention, Export, Import: (the pragmas are to be obsolescent) Modify B.1(28) as follows: Import, Export, and Convention pragmas are representation pragmas that specify the [c]{C}onvention aspect of representation{, using /convention_/identifiers that are identifiers specific to the Convention aspect}. In addition, Import and Export pragmas specify the [imported]{Import} and [exported]{Export (boolean)} aspects of representation, respectively{, along with the External_Name and Link_Name (string) aspects}. {These aspects may also be specified using an aspect_specification associated with the named entity, so long as the Import and Export aspect are not both specified as True for a single entity, and the External_Name or the Link_Name aspect are specified only if the Import or Export aspect is specified as True. [Redundant: In the absence of an interfacing pragma or an aspect_specification for the Convention aspect, the Convention aspect defaults to Ada for a user-declared entity, unless specified otherwise in this International Standard (see 6.3.1).]} Add a new clause to Annex J: [Note: The subclauses will be rearranged in alphabetical order - at the last moment. Also, these pragmas will be indexed in the pragma Annex L; we don't want people to freak out when they can't find pragma Pack or pragma Inline there (and it will lead them to the right place).] J.15 Aspect-related pragmas Pragmas can be used as an alternative to aspect_specifications to specify certain aspects. J.15.1 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.2 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.3 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.4 Pragma Controlled Syntax The form of a pragma Controlled, which is a representation pragma (see 13.1), is as follows: pragma Controlled(first_subtype_local_name); Legality Rules The first_subtype_local_name of a pragma Controlled shall denote a non-derived access subtype. Static Semantics A pragma Controlled specifies that the Controlled aspect (see 13.11.3) for the type denoted by *first_subtype_*local_name has the value True. J.15.5 Pragma Unchecked_Union Syntax The form of a pragma Unchecked_Union, 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.6 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. J.15.7 Pragma Priority and Pragma 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. At most one such pragma shall appear within a given construct. 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_definition 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_definition 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.8 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. At most one such pragma shall appear within a given construct. 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_definition that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma. J.15.9 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. At most one such pragma shall appear within a given construct. 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_definition that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma. J.15.10 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 of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma. J.15.11 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 Attach_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 A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the protected procedure handler_name to have the value True. A pragma Attach_Handler specifies the Attach_Handler aspect for the protected procedure handler_name to have the value of the given expression [Redundant: as evaluated at object creation time]. J.15.12 pragma Preelaborable_Initialization Syntax The form of a pragma Preelaborable_Initialization is as follows: pragma Preelaborable_Initialization (direct_name); Static Semantics A pragma Preelaborable_Initialization specifies the Preelaborable_Initialization aspect (see 10.2.1) of the type denoted by its argument is True. [Editor's note: This is not a representation pragma since this is an operational aspect. Representation pragmas cannot be specified on partial views by 13.1(9).] Legality Rules A Preelaborable_Initialization pragma shall appear in the visible part of a package or generic package. If the pragma appears in the first list of basic_declarative_items of a package_specification, then the direct_name shall denote the first subtype of a composite type such that the Preelaborable_Initialization aspect of the type may be specified to be True, and the type shall be declared immediately within the same package as the pragma. If the pragma appears in a generic_formal_part, then the direct_name shall denote a composite generic formal type declared in the same generic_formal_part as the pragma such that the Preelaborable_Initialization aspect of the type may be specified to be True. In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit. *** Additional obsolescent pragmas here *** Rearrange Annex K: Annex K (informative) Language-Defined Aspects and Attributes This annex summarizes the definitions given elsewhere of the language-defined aspects and attributes. Some aspects have corresponding attributes, as noted. K.1 Language-Defined Aspects ...[etc] Precondition: Specifies a condition that must hold true in order to call a given subprogram. See 13.3.1. Size: Size in bits of a subtype or object See 13.3. K.2 Language-Defined Attributes ...[entire contents of old Annex K goes here.] !discussion The intent is that all existing representation and operational aspects can be used in an aspect_specification. In addition, we would like to allow as many pragmas as possible to be treated as aspects. To make sense as an aspect, a pragma has to be restricted to the scope of the entity. It has to have two parameters, the first is the entity, the second a name/expression of some type, which is then the type of the aspect. Or, if the second argument is an "identifier specific to a pragma", it could make sense if we invent "identifiers specific to an aspect". [TBD in AI05-0183-1.] Or it could have just one parameter, the entity, and the type of the aspect is Boolean (True/False means the pragma is present/absent). 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: 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. !ACATS test ACATS tests would be needed for this aspect. !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. ****************************************************************