!standard 13.2(5) 11-02-15 AI05-0229-1/02 !standard 13.11.3(5) !standard B.3.3(4) !standard E.4.1(8) !standard K.1(0) !class Amendment 10-10-25 !status work item 10-10-25 !status received 10-10-25 !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 penultimate paragraph of the Static Semantics in AI05-0183-1: All specifiable operational and representation attributes may be specified with an aspect_specification instead of an attribute_definition_clause (see 13.3). The attribute_designator is used for the aspect_mark. A representation pragma or program unit pragma that has a single argument that is a local_name may be specified by an aspect_specification, with the entity being the local_name and the aspect_mark being the same as the pragma name. The aspect_definition is expected to be of type Boolean. The expression shall be static with value True. [Editor's note: The "=> True" part can be omitted by an existing rule - see AI05-0183-1. An AARM Note seems like overkill as that rule will be only a couple of paragraphs away from this one.] In addition, other operational and representation aspects not associated with specifiable attributes may be specified, as specified elsewhere in this International Standard. Changes for individual pragmas: Representation pragmas: (Covered by the general wording). ===pragma Pack: 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(5): [A pragma Pack specifies the packing aspect of representation; ] {Pragma Pack is a representation pragmaRedundant[; it specifies the Pack aspect with the value True]. If the aspect Pack has the value True, } the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and [a pragma]{specifying} Pack causes packing only of the extension part. Modify C.6(21): If [a pragma Pack applies to]{the Pack aspect has the value True for} a type any of ... ===pragma No_Return 6.5.1(2): No changes needed for No_Return. ===pragma Controlled: Modify 13.11.3(5): A pragma Controlled is a representation pragma[ that specifies the controlled aspect of representation]. ===pragma Unchecked_Union: Modify B.3.3(4/2): Unchecked_Union is a representation pragma[, specifying the unchecked union aspect of representation]. Add Unchecked_Union to the index under "representation pragma". ===pragma Discard_Names: C.5(6): No changes needed for Discard_Names. ===pragma Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components: C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. ===pragma Asynchronous: Modify E.4.1(8): A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] Library unit pragmas: (Somewhat covered by the general wording) [Editor's note: We still need to recast these as aspects, and a particular kind of aspect in order to invoke the aspect-specific wording (particularly 13.1(9)). The general wording only provides the Boolean value and staticness rules.] ===pragma Pure: See AI05-0243-1. ===pragma Preelaborate: See AI05-0243-1. ===pragma Remote_Call_Interface See AI05-0243-1. ===pragma Remote_Types See AI05-0243-1. ===pragma Shared_Passive See AI05-0243-1. ===pragma All_Calls_Remote Replace E.2.3(16): A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the library unit to which it applies to the value True; the aspect can also be set by the aspect_specification of the library_item. If the All_Calls_Remote aspect of a library unit has the value True, the library unit shall be a remote call interface. Modify E/2/3(19/1): If [a pragma]{aspect} All_Calls_Remote [applies to]{has the value True for} a given RCI library unit, ... ===pragma Elaborate_Body Replace 10.2.1(25): If the aspect Elaborate_Body has the value True for a declaration, then the declaration requires a completion (body). Delete the last sentence of 10.2.1(26), then add a new paragraph following: A pragma Elaborate_Body sets the Elaborate_Body representation aspect of the library unit to which it applies to the value True; the aspect can also be set by the aspect_specification of the library_item. If the Elaborate_Body aspect of a library unit has the value True, the body of the library unit is elaborated immediately after its declaration. Program unit pragmas: (Somewhat covered by the general wording) [Editor's note: We still need to recast these as aspects, and a particular kind of aspect in order to invoke the aspect-specific wording (particularly 13.1(9)). The general wording only provides the Boolean value and staticness rules.] ===pragma Inline Modify 6.3.2(4): The pragma shall apply to{, or the Inline aspect shall be specified for,} one or more callable entities. Insert before 6.3.2(5): A pragma Inline sets the Inline representation aspect of the program unit to which it applies to the value True; the aspect can also be set by the aspect_specification of the library_item. Modify 6.3.2(5): If [a pragma Inline applies to]{aspect Inline has the value True for} a callable entity, this indicates that inline expansion is desired for all calls to that entity. If [a pragma Inline applies to]{aspect Inline has the value True for} a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram. Other pragmas: ===pragma Preelaborable_Initialization Replace 10.2.1(11.6/2): A pragma Preelaborable_Initialization sets the Preelaborable_Initialization operational aspect of the type denoted by direct_name to the value True; the aspect can also be set by the aspect_specification of the declaration of a type. The pragma shall only appear in the visible part of a package or generic package. The aspect Preelaborable_Initialization shall only be specified for a composite type declared in the visible part of a package or generic package. [Note: This has to be an operational aspect, in order to be allowed to appear on a partial view.] Replace the middle three sentences of 10.2.1(11.7/3): If the aspect has the value True for a private type or a private extension, the full view of the type shall have preelaborable initialization. If the aspect has the value True for a protected type, the protected type shall not have entries, and each component of the protected type shall have preelaborable initialization. If the aspect has the value True for any other composite type, the type shall have preelaborable initialization. Replace 10.2.1(11.8/3): If the pragma appears in a generic_formal_part, then the direct_name shall denote a generic formal private type or a generic formal derived type declared in the same generic_formal_part as the pragma. In a generic_instantiation the actual type corresponding to a generic formal type with the Preelaborable_Initialization aspect having the value True shall have preelaborable initialization. AARM Ramification: This aspect can be specified on generic formal types that might be composite. [Editor's Note: Better redo the AARM note in AI05-0183-1 to mention this!] [Editor: It might have been better to recast the entire "preelaborable_initialization" (PI) property as an operational aspect of the type. That would require a lot more rewording, as types that "have" PI would instead have the PI aspect with a value of True; types that have PI specified would have to be completed with full types that also have PI with a value of True, and so on. That seems like it would involve a lot of opportunities for errors, so I went with the minimal change (even though it doesn't make much sense logically).] ===pragma Interrupt_Handler Insert before C.3.1(7/3): Static Semantics The Attach_Handler and Interrupt_Handler representation aspects can be specified on a protected procedure; the aspect_mark is the same as the name of the aspect. When the Interrupt_Handler aspect is specified the aspect_definition is expected to be an expression of type Boolean. The expression shall be static with value True. When the Attach_Handler aspect_mark is specified, the aspect_definition is expected to the an expression of type Interrupts.Interrupt_Id. A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the protected procedure handler_name to have the value True. A pragma Attach_Handler specifies the AttacheHandler aspect for the protected procedure handler_name to have the value of the given expression Redundant[as evaluated at object creation time]. Delete the last sentence of C.3.1(7/3) [it is being moved down]. Add after C.3.1(7/3): If either the Attach_Hander or Interrupt_Handler aspect are specifed for a protected procedure, it shall have a parameterless profile, the corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration, and shall not be declared within a generic body. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Replace C.3.1(9): If a protected procedure has the aspect Interrupt_Handler with the value True, then the procedure can be attached dynamically, as a handler, to interrupts (see C.3.2). Redundant[Such procedures are allowed to be attached to multiple interrupts.] Replace C.3.1(10): The value of the Attach_Handler aspect specifies an interrupt. As part of the initialization of the associated object, if the Attach_Handler aspect is specified, the handler procedure is attached to the specified interrupt. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected. Modify C.3.1(11/2): If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which either {the}[an] Attach_Handler or Interrupt_Handler [pragma applies to]{aspect is specified for} one of its procedures, a check is made that the ceiling priority defined in the protected_definition is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised. Modify C.3.1(12/1): When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If [an Attach_Handler pragma was used]{the Attach_Handler aspect was specified} and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored. Modify C.3.1(14/1/1): If the handlers for a given interrupt attached via [pragma]{aspect} Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via [pragma]{aspect} Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized. Modify C.3.1(17): When the [pragmas]{aspects} Attach_Handler or Interrupt_Handler [apply to]{are specified for} a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body. Modify C.3.1(19): Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler pragmas {and aspects} are allowed to be used for other, implementation defined, forms of interrupt handlers. Modify C.3.1(22): The Attach_Handler {aspect}[pragma] can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.) [Also, make similar changes to the AARM notes at the end of the clause.] ===pragma Storage_Size [Note: The existing attribute allows specification of Storage_Size for a task type *but* that attribute is obsolescent! Moreover, it would evaluate the expression too soon (when the type is frozen). I wrote specific wording to match the pragma. Not sure how to resolve the conflict with the obsolescent attribute, I used a TBH. Perhaps AI-183 needs to say something about not using "automatic" aspects if there is one with the same name explicitly defined??] Modify 13.3(60): ...used by some implementations.) If [a pragma Storage_Size is given]{the aspect Storage_Size is specified for the type of the object}, the value of the Storage_Size attribute is at least the value [specified in the pragma]{determined by the aspect}. [Editor's note: This last sentence is redundant with the wording below. The original wording is wrong, since the value is not "specified in the pragma", it is determined when the pragma is elaborated.] Add after 13.3(61): Static Semantics The representation aspect Storage_Size may be specified for a task_type_declaration or a single_task_declaration. The value of the aspect is an expression. AARM To Be Honest: This definition conflicts with the "automatic" one for the obsolescent attribute Storage_Size. We intend for that "automatic" one to not be used for that attribute. [Add an AARM note in J.9 to mention this.] Name Resolution Rules When the aspect Storage_Size is specified, the aspect_definition is an expression which is expected to be of any integer type. Dynamic Semantics When a task object with a specified Storage_Size is elaborated, the expression associated with the aspect is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the expression. At the point of task object creation, or upon task activation, Storage_Error is raised if there is insufficient free storage to accommodate the requested Storage_Size. Delete 13.3(66-67), replacing them by: Static Semantics The pragma Storage_Size sets the Storage_Size aspect of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma. ===pragma Relative_Deadline Delete the last sentence of D.2.6(6/2) [it follows from the aspect rules.] Add after D.2.6(9/2): The Relative_Deadline representation aspect can be specified on a task_type_declaration, a single_task_declaration, a subprogram_declaration. The value of the aspect is an expression. [Note: We have to use "subprogram_declaration" here, as aspects are not allowed in bodies. In the case of specifying this for the main subprogram, the pragma might be preferred to the aspect because a separate specification is not required.] When the aspect Relative_Deadline is specified, the aspect_definition is an expression which is expected to be of type Real_Time.Time_Span. The pragma Relative_Deadline sets the Relative_Deadline aspect of the enclosing task or subprogram to the relative_deadline_expression. Replace D.2.6(12/2): The Relative_Deadline aspect has no effect if it is specified for a subprogram other than the main subprogram. Modify D.2.6(13/2): The initial absolute deadline of a task {for which the}[containing pragma] Relative_Deadline {aspect is specified} is the value of Real_Time.Clock + [relative_deadline_]expression{ of the aspect}, where the call of Real_Time.Clock is made between task creation and the start of its activation. If there is no Relative_Deadline [pragma]{aspect} then the initial absolute deadline of a task is the value of Default_Deadline. [The environment task is also given an initial deadline by this rule.] ===pragma CPU [Editor's note: I've left the definition of the pragma, mainly because using the aspect is annoying for the main subprogram. See Relative_Deadline for more discussion.] Replace D.16(9/3): [Note: The original wording here is ambiguous.] When the aspect CPU is specified, the aspect_definition is an expression which is expected to be of type System.Multiprocessors.CPU_Range. The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range. Add after D.16(9/3): Static Semantics The CPU representation aspect can be specified on a task_type_declaration, a single_task_declaration, a subprogram_declaration. The value of the aspect is an expression. The pragma CPU sets the CPU aspect of the enclosing task or subprogram to the expression. Delete the second sentence of D.16(10/3). [This follows from the rules for aspects.] Add to the end of D.16(11/3): If the CPU aspect is specified for a subprogram, the expression shall be static. Modify D.16(12-4/3): The expression [of a CPU pragma that appears in a task_definition]{specifed for the CPU aspect of a task} is evaluated for each task object (see 9.1). The CPU value is then associated with the task object whose [task_definition contains the pragma]{task declaration specifies the aspect}. [A CPU pragma]{The CPU aspect} has no effect if it {is specified for a subprogram}[occurs immediately within the declarative_part of a subprogram_body] other than the main subprogram; the CPU value is not associated with any task. The CPU value is associated with the environment task if [the pragma appears in the declarative_part of]{the CPU aspect is specified for} the main subprogram. If [a pragma CPU does not apply to]{the CPU aspect is not specified for} the main subprogram it is implementation defined on which processor the environment task executes. ===pragma Interrupt_Priority, Priority Add after D.1(5): Static Semantics The Priority and Interrupt_Priority representation aspects can be specified on a task_type_declaration, a single_task_declaration, a subprogram_declaration. The value of the aspects is an expression. The pragma Priority sets the Priority aspect of the enclosing task or subprogram to the expression. The pragma Interrupt_Priority sets the Interrupt_Priority aspect of the enclosing task or subprogram to the expression, if any. If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last. Add to the end of D.1(6): When the aspect Priority or Interrupt_Priority is specified, the aspect_definition is an expression which is expected to be of type Integer. Delete the last sentence of D.1(7) [handled below] Replace D.1(8): If the Priority aspect is specified for a subprogram, the expression shall be static, and its value shall be in the range of System.Priority. Add after D.1(8): At most one of the Priority and Interrupt_Priority aspects may be specified for a given entity. AARM Ramification: This includes specifying via pragmas. Delete D.1(13). [This is covered by other wording.] Replace D.1(14): [A Priority pragma]{The Priority aspect} has no effect if it {is specified for a subprogram}[occurs immediately within the declarative_part of a subprogram_body] other than the main subprogram{; the Priority value is not associated with any task}. [Note: We added the last part as a clarification for CPU, it should be here, too.] Modify D.1(16): The effect of specifying [such a pragma in]{a Priority or Interrupt_Priority for} a protected_definition is discussed in D.3. Modify D.1(17): The expression [in a Priority or Interrupt_Priority pragma that appears in a task_definition]{specified for the Priority or Interrupt_Priority aspect of a task} is evaluated for each task object (see 9.1). For [a]{the} Priority [pragma]{aspect}, the value of the expression is converted to the subtype Priority; for [an]{the} Interrupt_Priority [pragma]{aspect}, this value is converted to the subtype Any_Priority. The priority value is then associated with the task object whose [task_definition contains the pragma]{task declaration specifies the aspect}. Modify D.1(18): Likewise, the priority value is associated with the environment task if the {aspect is specified for}[pragma appears in the declarative_part of] the main subprogram. Change "pragma" to "aspect" in D.1(19). Modify D.3(6/2): The expression [in a Priority or Interrupt_Priority pragma task_definition]{specified for the Priority or Interrupt_Priority aspect} (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. If no Priority or Interrupt_Priority [pragma applies to]{aspect is specified for} a protected object, the initial priority is specified by the locking policy. Replace "pragma" by "aspect" in D.3(8/2). Modify D.3(10/2): If an Interrupt_Handler or Attach_Handler [pragma]{aspect} (see C.3.1) [appears in a protected_definition]{is specified for a protected subprogram of a protected type that does not have the Interrupt_Priority aspect specified}[ without an Interrupt_Priority pragma], the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority. Replace D.3(11/2): If neither aspect Priority nor Interrupt_Priority is specified for a protected type, and no protected subprogram of the type has aspect Interrupt_Handler or Attach_Handler specified, then the initial priority of the corresponding protected object is System.Priority'Last. ===pragma Implemented See AI05-0215-1. *** TBD: Ed Schonberg. ===pragmas Convention, Export, Import: Modify B.1(28) as follows: Import, Export, and Convention pragmas are representation pragmas that specify the [c]{C}onvention aspect of representation{, using /convention_/identifiers that are identifiers specific to the Convention aspect}. In addition, Import and Export pragmas specify the [imported]{Import} and [exported]{Export (boolean)} aspects of representation, respectively{, along with the External_Name and Link_Name (string) aspects}. {These aspects may also be specified using an aspect_specification associated with the named entity, so long as the Import and Export aspect are not both specified as True for a single entity, and the External_Name or the Link_Name aspect are specified only if the Import or Export aspect is specified as True. [Redundant: In the absence of an interfacing pragma or an aspect_specification for the Convention aspect, the Convention aspect defaults to Ada for a user-declared entity, unless specified otherwise in this International Standard (see 6.3.1).]} Rearrange Annex K: Annex K (informative) Language-Defined Aspects and Attributes This annex summarizes the definitions given elsewhere of the language-defined aspects and attributes. Some aspects have corresponding attributes, as noted. K.1 Language-Defined Aspects ...[etc] Precondition: Specifies a condition that must hold true in order to call a given subprogram. See 13.3.1. Size: Size in bits of a subtype or object See 13.3. K.2 Language-Defined Attributes ...[entire contents of old Annex K goes here.] !discussion The intent is that all existing representation and operational aspects can be used in an aspect_specification. In addition, we would like to allow as many pragmas as possible to be treated as aspects. To make sense as an aspect, a pragma has to be restricted to the scope of the entity. It has to have two parameters, the first is the entity, the second a name/expression of some type, which is then the type of the aspect. Or, if the second argument is an "identifier specific to a pragma", it could make sense if we invent "identifiers specific to an aspect". [TBD in AI05-0183-1.] Or it could have just one parameter, the entity, and the type of the aspect is Boolean (True/False means the pragma is present/absent). Following is a list of all Ada pragmas, listed in ---------------- Boolean representation aspects: pragma Asynchronous(local_name); - See E.4.1. pragma Atomic(local_name); - See C.6. pragma Atomic_Components(array_local_name); - See C.6. pragma Controlled(first_subtype_local_name); - See 13.11.3. pragma Discard_Names[([On => ] local_name)]; - See C.5. pragma Independent(component_local_name); - See C.6. pragma Independent_Components(local_name); - See C.6. pragma Pack(first_subtype_local_name); - See 13.2. pragma Volatile(local_name); - See C.6. pragma Volatile_Components(array_local_name); - See C.6. pragma Unchecked_Union (first_subtype_local_name); - See B.3.3. Note: For representation pragmas, 13.1(8/3) specifies that the pragma specifies an aspect and the name of that aspect. Thus, we don't need any wording in these pragmas about "aspects of representation"; we get rid of extra such wording for consistency. ---------------- Pragmas that could be Boolean operational or representation aspects: pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3. pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1. pragma Inline(name {, name}); - See 6.3.2. pragma Interrupt_Handler(handler_name); - See C.3.1. pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1. pragma Preelaborable_Initialization(direct_name); - See 10.2.1. pragma Preelaborate[(library_unit_name)]; - See 10.2.1. pragma Pure[(library_unit_name)]; - See 10.2.1. pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3. pragma Remote_Types[(library_unit_name)]; - See E.2.2. pragma Shared_Passive[(library_unit_name)]; - See E.2.1. ---------------- Pragmas that could be other (normal) operational or representation aspects: pragma Attach_Handler(handler_name, expression); - See C.3.1. -- Aspect type is Interrupts.Interrupt_ID. pragma CPU (expression); - See D.16. -- Aspect type is System.Multiprocessors.CPU_Range. -- And this implicitly applies to outer task/prot. or PROCEDURE! pragma Interrupt_Priority[(expression)]; - See D.1. -- Aspect type is Integer. -- Does the aspect have a default value? (no.) pragma Priority(expression); - See D.1. -- Aspect type is Integer. -- Require static in procedure? pragma Relative_Deadline (relative_deadline_expression); - See D.2.6. -- Aspect type is Real_Time.Time_Span. pragma Storage_Size(expression); - See 13.3. -- Aspect type is universal_integer? ---------------- Pragmas that could be other (normal) operational or representation aspects if we have a mechanism for "identifiers specific to an aspect": pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name); - See B.1. -- Note that the parameters are backwards pragma Implemented(procedure_local_name, implementation_kind); - See 9.5. pragma Export( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. -- Only if split into multiple aspects. pragma Import( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. -- Only if split into multiple aspects. ---------------- Make no sense as aspects: pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2. pragma Assertion_Policy(policy_identifier); - See 11.4.2. pragma Detect_Blocking; - See H.5. pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1. pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 10.2.1. pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2. pragma Linker_Options(string_expression); - See B.1. pragma List(identifier); - See 2.8. pragma Locking_Policy(policy_identifier); - See D.3. pragma Normalize_Scalars; - See H.1. pragma Optimize(identifier); - See 2.8. pragma Page; - See 2.8. pragma Partition_Elaboration_Policy (policy_identifier); - See H.6. pragma Priority_Specific_Dispatching ( policy_identifier, first_priority_expression, last_priority_expression); - See D.2.2. pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13. pragma Queuing_Policy(policy_identifier); - See D.4. pragma Restrictions(restriction{, restriction}); - See 13.12. pragma Reviewable; - See H.3.1. pragma Suppress(identifier); - See 11.5. pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2. pragma Unsuppress(identifier); - See 11.5. !ACATS test ACATS tests would be needed for this aspect. !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? ****************************************************************