Version 1.18 of ai05s/ai05-0229-1.txt

Unformatted version of ai05s/ai05-0229-1.txt version 1.18
Other versions for file ai05s/ai05-0229-1.txt

!standard 13.2(5) 11-08-05 AI05-0229-1/12
!standard 2.8(29/2)
!standard 3.7(37/2)
!standard 4.8(15)
!standard 6.3.2(2)
!standard 6.3.2(3)
!standard 6.3.2(4)
!standard 6.3.2(5)
!standard 6.3.2(6)
!standard 6.3.2(6.1/2)
!standard 6.3.2(7)
!standard 6.5.1(1/2)
!standard 6.5.1(2/2)
!standard 6.5.1(3/2)
!standard 6.5.1(4/2)
!standard 6.5.1(8/2)
!standard 6.5.1(10/2)
!standard 9.10(1)
!standard 10.1.4(7/2)
!standard 10.2.1(25)
!standard 10.2.1(26)
!standard 11.4.1(4/2)
!standard 11.5(7.2/2)
!standard 11.6(6)
!standard 13.2(1)
!standard 13.2(2)
!standard 13.2(3)
!standard 13.2(4)
!standard 13.2(5)
!standard 13.2(7)
!standard 13.3(38)
!standard 13.3(58)
!standard 13.3(60)
!standard 13.3(61)
!standard 13.3(62)
!standard 13.3(63)
!standard 13.3(64)
!standard 13.3(65)
!standard 13.3(66)
!standard 13.3(73)
!standard 13.3.1(0)
!standard 13.6(1)
!standard 13.8(13)
!standard 13.11.3(1)
!standard 13.11.3(2)
!standard 13.11.3(3)
!standard 13.11.3(4)
!standard 13.11.3(5)
!standard 13.11.3(6)
!standard 13.11.3(7)
!standard 13.11.3(8)
!standard 13.12.1(4/2)
!standard A.1(37)
!standard A.1(42)
!standard A.1(42.1/2)
!standard B.1(1)
!standard B.1(2)
!standard B.1(4)
!standard B.1(5)
!standard B.1(6)
!standard B.1(7)
!standard B.1(9.1/1)
!standard B.1(10)
!standard B.1(11)
!standard B.1(14)
!standard B.1(21)
!standard B.3(23)
!standard B.3(33)
!standard B.3(34)
!standard B.3(39.5/2)
!standard B.3(39.6/2)
!standard B.3(39.14/2)
!standard B.3(39.15/2)
!standard B.3.3(1/2)
!standard B.3.3(2/2)
!standard B.3.3(3/2)
!standard B.3.3(4/2)
!standard B.3.3(5/2)
!standard B.3.3(6/2)
!standard B.3.3(29/2)
!standard B.4(12)
!standard B.4(16)
!standard B.4(20)
!standard B.4(29)
!standard B.5(12)
!standard C.3.1(1)
!standard C.3.1(2)
!standard C.3.1(3)
!standard C.3.1(4)
!standard C.3.1(5)
!standard C.3.1(6)
!standard C.3.1(7/2)
!standard C.3.1(9)
!standard C.3.1(10)
!standard C.3.1(11/2)
!standard C.3.1(12/1)
!standard C.3.1(14.1/1)
!standard C.3.1(17)
!standard C.3.1(19)
!standard C.3.1(22)
!standard C.3.2(17)
!standard C.3.2(21)
!standard C.3.2(24)
!standard C.3.2(28)
!standard C.6(21)
!standard D.1(2)
!standard D.1(3)
!standard D.1(4)
!standard D.1(5)
!standard D.1(6)
!standard D.1(7)
!standard D.1(8)
!standard D.1(13)
!standard D.1(14)
!standard D.1(16)
!standard D.1(17)
!standard D.1(18)
!standard D.1(19)
!standard D.2.6(2/2)
!standard D.2.6(3/2)
!standard D.2.6(4/2)
!standard D.2.6(5/2)
!standard D.2.6(6/2)
!standard D.2.6(9/2)
!standard D.2.6(12/2)
!standard D.2.6(13/2)
!standard D.3(6.1/2)
!standard D.3(8/2)
!standard D.3(10/2)
!standard D.3(11/2)
!standard D.13(5/2)
!standard D.16(0)
!standard E.2.3(13)
!standard E.2.3(16)
!standard E.2.3(19/1)
!standard E.4.1(1)
!standard E.4.1(2)
!standard E.4.1(3)
!standard E.4.1(4)
!standard E.4.1(5)
!standard E.4.1(6)
!standard E.4.1(7)
!standard E.4.1(8)
!standard E.4.1(9)
!standard J.15(0)
!standard J.15.1(0)
!standard J.15.2(0)
!standard J.15.3(0)
!standard J.15.4(0)
!standard J.15.5(0)
!standard J.15.6(0)
!standard J.15.7(0)
!standard J.15.8(0)
!standard J.15.9(0)
!standard J.15.11(0)
!standard J.15.12(0)
!standard J.15.13(0)
!standard K.1(0)
!class Amendment 10-10-25
!status Amendment 2012 11-06-06
!status ARG Approved (by Letter Ballot) 9-1-1 11-05-16
!status work item 10-10-25
!status received 10-10-25
!priority Medium
!difficulty Easy
!subject Specifiable aspects

!summary

(See proposal.)

!problem

The new aspect clauses (see AI05-0183-1) provide convenient syntax for specifying aspect values. We ought to be able to use that syntax to specify existing aspects as well as new ones.

!proposal

Rewrite as needed to make many pragmas into aspects.

!wording

Replace the sixth paragraph from the end of the Static Semantics in AI05-0183-1/11 (13.3.1(30/3) in draft 11.5):

All specifiable operational and representation attributes may be specified with an aspect_specification instead of an attribute_definition_clause (see 13.3).

AARM Ramification: The name of the aspect is the same as that of the attribute (see 13.3), so the aspect_mark is the name of the attribute. [Editor's Note: 13.3(5/3), from AI05-0183-1; but we can't put paragraph numbers into AARM notes. We need this note here because this rule is far away in the standard.]

Any aspect specified by a representation pragma or library unit pragma that has a local_name as its single argument may be specified by an aspect_specification, with the entity being the local_name. The aspect_definition is expected to be of type Boolean. The expression shall be static.

AARM Ramification: The name of the aspect is the same as that of the pragma (see 13.1), so the aspect_mark is the name of the pragma. [Editor's Note: 13.1(8/3), from AI05-0112-1; but we can't put paragraph numbers into AARM notes. We need this note here because this rule is far away in the standard.]

[Editor's notes: The "=> True" part may be omitted by an existing rule - see AI05-0183-1. An AARM Note seems like overkill as that rule will be only a couple of paragraphs away from this one.

This rule is mostly for the pragmas that are now moved to Annex J. We might consider moving this to Annex J as well - but we're not going to do that for the definition of representation pragmas in 13.1 (as it is too hard to extract) - so it OK to leave it here as well. Any preference??]

In addition, other operational and representation aspects not associated with specifiable attributes or representation pragmas may be specified, as specified elsewhere in this International Standard.

Modify 13.12.1(4/2):

No_Obsolescent_Features

There is no use of language features defined in Annex J. It is implementation-defined if uses of the renamings of J.1 {and of the pragmas of J.15} are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.

AARM Note: The pragmas have exactly the functionality of the corresponding aspect, (unlike the typical obsolescent feature) and rejecting them could be a significant portability problem for existing code.

Changes for individual pragmas:

Representation pragmas: (Covered by the general wording).

===pragma Pack: (the pragma is to be obsolescent)

Change the title of clause 13.2 to "Packed types". [Editor's note: Could have used "Aspect Pack" instead, but this seems more meaningful, and more like the inline clause. Similar comments apply to all of the other clauses that were named "pragma Something".]

Change "packing" to "Pack" in 13.3(55.e), 13.3(73), 13.3(73.a), 13.1(7.g), 9.10(1/3), 9.10(1.c), 13.6(1).

[Note: We're only changing uses where "packing is specified" or the like.]

Modify 13.2(1):

[Redundant: {The Pack aspect having the value True}[A pragma Pack] specifies that storage minimization should be the main criterion when selecting the representation of a composite type.]

Delete 13.2(2-4). [Now in Annex J.]

Replace 13.2(5):

For a full type declaration of a composite type, the following language-defined representation aspect may be specified:

Pack

The type of aspect Pack is Boolean. When aspect Pack is True for a type, the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and specifying Pack causes packing only of the extension part.

If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.

[Editor's Note: We say "full type declaration" in order to encapsulate all of the rules about requiring a "first subtype" and not a partial view. This is somewhat redundant with the rules in 13.1 for representation aspects, but it seems good to be clear.]

Modify AARM 13.2(6.a):

{Specifying the Pack aspect}[A pragma Pack] is for gaining space efficiency, possibly at the expense of time. If more explicit control over representation is desired, then a record_representation_clause, a Component_Size clause, or a Size clause should be used instead of, or in addition to, {the Pack aspect}[a pragma Pack].

Modify 13.2(7):

The recommended level of support for {the Pack aspect}[pragma Pack] is:

Modify AARM Notes 13.2(9.b-d/2), replacing "pragma Pack" with "the Pack aspect".

Modify A.1(37) to use the Pack aspect rather than the pragma:

type String is array(Positive range <>) of Character{ with Pack}; [ pragma Pack(String);]

Modify A.1(42), A.1(42.1/2), B.4(12), B.4(16), B.4(20), B.4(29), B.5(12) to use the Pack aspect rather than the pragma as described above.

In B.3(23), delete "pragma Pack" (it is bogus to have both Pack and Component_Size specified for the same type; Pack is ineffective in that case).

Add "with Pack" to B.3(33), B.3(39.5/2), and B.3(39.14/2).

Delete B.3(34), B.3(39.6/2), and B.3(39.15/2) [which are just pragma Pack].

Modify C.6(21):

If [a pragma Pack applies to]{the Pack aspect is True for} a type any of ...

AARM notes in 13.1 and 13.3 need modification from "pragma Pack" to "aspect Pack".

===pragma No_Return (the pragma is to be obsolescent)

Change the title of clause 6.5.1 to "Non-returning Procedures".

Modify 6.5.1(1/2):

{Specifying aspect No_Return to have the value True}[A pragma No_Return] indicates that a procedure cannot return normally [Redundant:; it may propagate an exception or loop forever].

Delete 6.5.1(2-3/2). [Now in Annex J.]

Add before 6.5.1(4/2):

Static Semantics

For a procedure or generic procedure, the following language-defined representation aspect may be specified:

No_Return

The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be non-returning.

If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False.

Move 6.5.1(8/2) to this point (keeping the Static Semantics together).

Replace 6.5.1(4/2): [Start of Legality Rules]

Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit.

Modify 6.5.1(10/2):

procedure Fail(Msg : String)[;]; -- raises Fatal_Error exception with No_Return => True;} [pragma No_Return(Fail);] -- Inform compiler and reader that procedure never returns normally

Modify 11.4.1(4/2):

procedure Raise_Exception(E : in Exception_Id; Message : in String := ""){ with No_Return => True}; [pragma No_Return(Raise_Exception);]

[This is the only use of No_Return in an Ada predefined package.]

===pragma Controlled:

Delete the entire subclause 13.11.3.

Remove "(see 13.11.3)" from 4.8(15).

===pragma Unchecked_Union: (the pragma is to be obsolescent)

Change the title of clause B.3.3 to "Unchecked Union Types".

Modify B.3.3(1/2):

[Redundant: {Specifying aspect Unchecked_Union to have value True defines}[A pragma Unchecked_Union specifies] an interface correspondence between a given discriminated type and some C union. The {aspect requires}[pragma specifies] that the associated type {is}[shall be] given a representation that leaves no space for its discriminant(s).]

Add after B.3.3(1/2):

For a discriminated record type having a variant_part, the following language-defined representation aspect may be specified:

Unchecked_Union

The type of aspect Unchecked_Union is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.

Delete B.3.3(2-5/2) [Now in Annex J.]

Modify B.3.3(6/2):

A type {for}[to] which {aspect}[a pragma] Unchecked_Union {is True}[applies] is called an unchecked union type. A subtype of an unchecked union type is defined to be an unchecked union subtype. An object of an unchecked union type is defined to be an unchecked union object.

Delete B.3.3(29/2) (pragma Controlled has been removed).

===pragma Discard_Names:

[Editor's note: Can't get make this pragma obsolescent; its use as a configuration pragma or to apply to all entities in a package specification cannot be modeled as an aspect.

C.5: No changes needed for Discard_Names; the general wording for using representation pragmas as aspects applies here. But note that this is the only remaining representation pragma in the core.

Add an AARM Ramification after C.5(6): Representation pragmas are automatically aspects, so Discard_Names can be used as an aspect_mark in an aspect_specification instead of using the pragma on individual entities.

[Editor's note: We could try to reword this to recommend using an aspect rather than the (On => local_name) form, but it doesn't seem worth the effort. The AARM note is just to mention the possibility. We could also make something similar into a user note.]

===pragma Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components: (the pragmas are to be obsolescent)

Rewrite C.6(2-8)) as follows:

Static Semantics

For an object declaration, a component declaration, or a full type declaration, the following representation aspects can be specified: Atomic, Volatile, and Independent.

For a full type declaration of an array type (including the anonymous type of a object_declaration of an anonymous array object), the following representation aspects can be specified: Atomic_Components, and Volatile_Components.

For an object declaration of a full type declaration (including the anonymous type of a object_declaration of an anonymous array object), the following representation aspect can be specified: Independent_Components.

The type of these aspects is Boolean. If any of these aspects are directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), each of these aspects are False.

An atomic type is one for which the aspect Atomic is True. An atomic object (including a component) is one for which the aspect Atomic is True, or a component of an array for which the aspect Atomic_Components is True for the associated type, or any object of an atomic type, other than objects obtained by evaluating a slice.

A volatile type is one for which the aspect Volatile is True. A Volatile object (including a component) is one for which the aspect Volatile is True, or a component of an array for which the aspect Volatile_Components is True for the associated type, or any object of a volatile type. In addition, every atomic type or object is also defined to be volatile. Finally, if an object is volatile, then so are all of its subcomponents.

Delete C.6(9/3) [Now in Annex J.]

Replace C.6(10) with the following two paragraphs:

If aspect Independent_Components is specified for a full_type_declaration, the declaration shall be that of an array or record type.

[This rule is needed to replace the resolution rules of C.6(9/3) for items not previously included. We don't need a rule for components as there is no way to write an inherited component_declaration. We intend that all components and types to have the "regular" aspects. - RLB]

It is illegal to specify the aspect Atomic or Atomic_Components for an object or type if the implementation cannot support the indivisible reads and writes required by the aspect (see below).

Replace C.6(13):

If an aspect Volatile, Volative_components, Atomic or Atomic_Components is directly specified to have the value True for an stand-alone constant object, then the aspect Import shall also be specified for it.

AARM To Be Honest: Volatile_Components and Atomic_Components actually are aspects of the anonymous array type; this rule only applies when the aspect is specified directly on the constant object and not when the (named) array type has the aspect.

It is illegal to specify the aspect Independent or Independent_Components as True for a component, object or type if the implementation cannot provide the independent addressability required by the aspect (see 9.10).

It is illegal to specify a representation aspect for a component, object or type for which the aspect Independent or Independent_Components is True, in a way that prevents the implementation from providing the independent addressability required by the aspect.

Delete C.6(14) [Now in Annex J.]

Replace C.6(14.1/3):

When True, the aspects Independent and Independent_Components *specify as independently addressable* the named object or component(s), or in the case of a type, all objects of that type. All atomic objects are considered to be specified as independently addressable.

===pragma Asynchronous: (the pragma is to be obsolescent)

Change the title of clause E.4.1 to "Asynchronous Remote Calls".

Modify E.4.1(1):

[Redundant: This subclause introduces the {aspect}[pragma] Asynchronous which {which can be specified to allow}[allows] a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body.]

Delete E.4.1(2-3). [Now in Annex J.]

Add after E.4.1(3):

For a remote procedure, the following language-defined representation aspect may be specified:

Asynchronous

The type of aspect Asynchronous is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified, the aspect is False.

For a remote access type, the following language-defined representation aspect may be specified:

Asynchronous The type of aspect Asynchronous is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.

Replace E.4.1(4-7) with:

If aspect Asynchronous is specified for a remote procedure, the formal parameters of the procedure shall all be of mode in.

If aspect Asynchronous is specified for a remote access type, the type shall be a remote access-to-class-wide type, or the type shall be a remote access-to-procedure type with the formal parameters of the designated profile of the type all of mode in.

Delete E.4.1(8).

Modify E.4.1(9):

A remote call is asynchronous if it is a call to a procedure, or a call through a value of an access-to-procedure type, to which {aspect}[a pragma] Asynchronous {is True}[applies]. In addition, if {aspect}[a pragma] Asynchronous {is True}[applies] to a remote access-to-class-wide type, then a dispatching call on a procedure with a controlling operand designated by a value of the type is asynchronous if the formal parameters of the procedure are all of mode in.

Edit AARM notes E.4(20.g-20.h) to replace "pragma Asychronous is applied" with "aspect Asychronous is specified". E.4(20.i) "pragma" becomes "aspect".

Library unit pragmas:

[Editor's note: We still need to mention that these are also aspects, even though the general wording for library unit pragmas provides the Boolean value and staticness rules. We don't add any rules that prevent giving both the pragma and the aspect, since it is OK to give the pragma more than once. Also note that for pragmas that are usually used with library units, we're keeping the pragmas as the primary way to specify these things (they're not moving to Annex J).]

===pragma Pure:

See AI05-0243-1.

===pragma Preelaborate:

See AI05-0243-1.

===pragma Remote_Call_Interface

See AI05-0243-1.

===pragma Remote_Types

See AI05-0243-1.

===pragma Shared_Passive

See AI05-0243-1.

===pragma All_Calls_Remote

[Editor's note: As a pragma that applies to a package, we're not going to make it obsolescent.]

Replace E.2.3(16):

A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the library unit to which it applies to the value True. If the All_Calls_Remote aspect of a library unit is True, the library unit shall be a remote call interface.

Modify E.2.3(19/1):

If [a pragma]{aspect} All_Calls_Remote [applies to]{is True for} a given RCI library unit, ...

===pragma Elaborate_Body

[Editor's note: As a pragma that applies to a package, we're not going to make it obsolescent. But note that we still have to write the semantics in terms of the aspect so that whether the pragma or aspect is used is irrelevant.]

Replace 10.2.1(25):

If the aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (body).

Delete the last sentence of 10.2.1(26), then add a new paragraph following:

A pragma Elaborate_Body sets the Elaborate_Body representation aspect of the library unit to which it applies to the value True. If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.

===pragma Inline (the pragma is to be obsolescent)

Delete 6.3.2(2-4). [Now in Annex J.]

Replace 6.3.2(5) with

For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified:

Inline

The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.

If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False.

Modify 6.3.2(6):

For each call, an implementation is free to follow or to ignore the recommendation {determined}[expressed] by the {Inline aspect}[pragma].

Delete 6.3.2(6.1/2).

Delete AARM Notes 6.3.2(5.a-5.c) [but not 5.d], 6.3.2(6.b-c/2).

Delete 6.3.2(7).

Replace Inline in 2.8(29/2):

pragma Pure(Rational_Numbers); -- Set the categorization of package Rational_Numbers (see 7.1)

Modify the last sentence of 10.1.4(7/2):

If the given compilation unit contains the body of a subprogram {for}[to] which {aspect}[a @fa<pragma>] Inline {is True}[applies], the implementation may also remove any compilation unit containing a call to that subprogram.

Modify 11.5(7.2/2):

"...to a subprogram {for which aspect}[that has a pragma] Inline {is True}[applied to it],..."

Modify 11.6(6):

"..., and {for which the}[has no] Inline {aspect is False}[pragma applied to it]. ..."

Modify 13.8(13):

M : Mask; procedure Set_Mask{ with Inline};[ pragma Inline(Set_Mask);]

Other pragmas:

===pragma Preelaborable_Initialization (referred to as P_I below)

[Editor's Note: This pragma does not work well as a type-related aspect, as it is view dependent. In particular, even if a partial view does not have the P_I property, the full view might have the P_I property. That is contrary to 13.1(11/2) for operational and representation aspects. (In the absence of a change to 13.1(11/2), we'd have a compatibility problem.)

We could try to invent new rules specifically for the P_I aspect to handle this, but it is more work than this could possibly be worth (there is no requirement for this pragma to be an aspect).

Thus we are retaining the pragma and not defining an aspect.]

===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent)

Delete C.3.1(1-6) [Now in Annex J.]

Insert before C.3.1(7/3):

Static Semantics

For a parameterless protected procedure, the following language-defined representation aspects may be specified:

Interrupt_Handler

The type of aspect Interrupt_Handler is Boolean. If directly specified, the aspect_definition shall be a static expression. [Redundant: This aspect is never inherited;] if not directly specified, the aspect is False.

Attach_Handler

The value of aspect Attach_Handler is an expression, which shall be of type Interrupts.Interrupt_Id. [Redundant: This aspect is never inherited.]

Delete C.3.1(7/3). [Also in Annex J.]

Add after C.3.1(7/3):

If either the Attach_Hander or Interrupt_Handler aspect are specifed for a protected procedure, the corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration and shall not be declared within a generic body. In addition to the places where Legality Rules normally apply (see 12.3), this rules also apply in the private part of an instance of a generic unit.

Replace C.3.1(9):

If the Interrupt_Handler aspect of a protected procedure is True, then the procedure may be attached dynamically, as a handler, to interrupts (see C.3.2). [Redundant: Such procedures are allowed to be attached to multiple interrupts.]

[Editor's note: We change "can" to "may" to eliminate a banned word in ISO standards, here and elsewhere in this clause.]

Replace C.3.1(10):

The expression specified for the Attach_Handler aspect of a protected procedure P is evaluated as part of the creation of the protected object that contains P. The value of the expression identifies an interrupt. As part of the initialization of that object, P (the @fa<handler> procedure) is attached to the identified interrupt. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected.

Modify C.3.1(11/2):

If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object {that contains a protected procedure} for which either {the}[an] Attach_Handler {aspect is specified} or {the} Interrupt_Handler [pragma applies to]{aspect is True}[ one of its procedures], a check is made that the {initial} ceiling priority {of the object (see D.3)}[defined in the protected_definition] is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised.

If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True for one of its procedures, a check is made that the initial ceiling priority of the object is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised.

Modify C.3.1(12/1):

When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If [an Attach_Handler pragma was used]{the Attach_Handler aspect was specified} and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored.

Modify C.3.1(14/1/1):

If the handlers for a given interrupt attached via [pragma]{aspect} Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via [pragma]{aspect} Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized.

Modify C.3.1(17):

When the [pragmas]{aspects} Attach_Handler or Interrupt_Handler [apply to]{are specified for} a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body.

Modify C.3.1(19):

Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler [pragmas]{aspects} are allowed to be used for other, implementation defined, forms of interrupt handlers.

Modify C.3.1(22):

The Attach_Handler {aspect may}[pragma can] provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)

[Also, make similar changes to the AARM notes at the end of the clause.]

===pragma Storage_Size (the pragma is to be obsolescent)

[Editor's note: The existing attribute allows specification of Storage_Size for a task type but that attribute is obsolescent! Moreover, it would evaluate the expression too soon (when the type is frozen). My presumption is that this explicit wording overrides the "automatic" aspect implied by the obsolescent attribute. I handled this with a pair of AARM notes, since I don't want to rewrite the wording of an obsolescent attribute nor rewrite the aspect_specification wording for this unusual case.]

Modify 13.3(60):

...used by some implementations.) If [a pragma Storage_Size is given]{the aspect Storage_Size is specified for the type of the object}, the value of the Storage_Size attribute is at least the value [specified in the pragma]{determined by the aspect}.

[Editor's note: This last sentence is redundant with the wording below. The original wording is wrong, since the value is not "specified in the pragma", it is determined when the pragma is elaborated.]

Add after 13.3(61):

Static Semantics

For a task type (including the anonymous type of a single_task_declaration), the following language-defined representation aspect may be specified:

Storage_Size

The value of aspect Storage_Size is an expression, which shall be of any integer type.

[Editor's note: I would have used the shorter wording "single task", but that term is not defined by the Standard. We do use it in a few AARM notes, but that isn't much help. Thus I used the longer wording.]

AARM To Be Honest: This definition somewhat conflicts with the "automatic" one for the obsolescent attribute Storage_Size. We intend for that "automatic" one to not be used for that attribute.

[Editor's note: Task types cannot be derived, so we don't have to worry about aspect inheritance, other than from task interfaces (a new possibility). We make those illegal (they can't be useful). The inabilility to derive also means we cannot run afoul of 13.1(10).]

Delete 13.3(62-65) [Now in Annex J.]

Add after 13.3(65):

Legality Rules

The Storage_Size aspect shall not be specified for a task interface type.

Replace 13.3(66) with:

When a task object is created, the expression (if any) associated with the Storage_Size aspect of its type is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the expression.

AARM Ramification: If the Storage_Size aspect is not specified for the type of the task object, the value of the Storage_Size attribute is unspecified.

Add after J.9(3/2):

AARM Ramification: When this attribute is specified with an attribute_definition_clause, the associated aspect is set to the value of the expression given in the attribute_definition_clause. This value is therefore the same for all objects of the type; in particular, it is not re-evaluated when objects are created. This is different than when the aspect is specified with an aspect_specification (see 13.3).

===pragma Interrupt_Priority, Priority (the pragmas are to be obsolescent)

[Editor's Note: I'd much prefer that there was only one aspect here, probably named "Base_Priority", but the rules about converting to subtype Any_Priority vs. to subtype Priority at evaluation time force two aspects. That's because these aspects are expressions that are evaluated when the task (or protected) object is elaborated, not values evaluated at the freezing point. Personally, I'd drop the two subtypes, but one presumes that there is some value to the bifrucation and in any case it is 30 years too late for that.]

Delete D.1(2-7) [Moved to Annex J.]

Add after D.1(5):

Static Semantics

For a task type (including the anonymous type of a single_task_declaration), protected type (including the anonymous type of a single_protected_declaration), or subprogram, the following language-defined representation aspects may be specified:

Priority

The value of aspect Priority is an expression, which shall be of type Integer.

Interrupt_Priority

The value of aspect Interrupt_Priority is an expression, which shall be of type Integer.

[Editor's Note: See the comment about "single task" in Storage_Size.]

[Editor's note: Task types and protected types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from synchronized interfaces (which we don't allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).]

Replace D.1(8):

If the Priority aspect is specified for a subprogram, the expression shall be static, and its value shall be in the range of System.Priority.

Add after D.1(8):

At most one of the Priority and Interrupt_Priority aspects may be specified for a given entity.

AARM Ramification: This includes specifying via pragmas (see J.15.11).

Neither of the Priority or Interrupt_Priority aspects shall be specified for a synchronized interface type.

Delete D.1(13). [This is covered by other wording, and seems to conflict with D.1(17) anyway. The definition of the value of the pragma is never used anywhere, so far as I can tell.]

Replace D.1(14):

[A Priority pragma]{The Priority aspect} has no effect if it {is specified for a subprogram}[occurs immediately within the declarative_part of a subprogram_body] other than the main subprogram{; the Priority value is not associated with any task}.

[Editor's Note: We added the last part as a clarification for aspect CPU, it should be here, too.]

Modify D.1(16):

The effect of specifying [such a pragma in a protected_definition]{a Priority or Interrupt_Priority aspect for a protected type or single_protected_declaration} is discussed in D.3.

Modify D.1(17):

The expression [in a Priority or Interrupt_Priority pragma that appears in a task_definition]{specified for the Priority or Interrupt_Priority aspect of a task} is evaluated for each task object (see 9.1). For [a]{the} Priority [pragma]{aspect}, the value of the expression is converted to the subtype Priority; for [an]{the} Interrupt_Priority [pragma]{aspect}, this value is converted to the subtype Any_Priority. The priority value is then associated with the task object whose [task_definition contains the pragma]{task declaration specifies the aspect}.

Modify D.1(18):

Likewise, the priority value is associated with the environment task if the {aspect is specified for}[pragma appears in the declarative_part of] the main subprogram.

Change "pragma" to "aspect" in D.1(19).

Modify D.3(6/2):

The expression [in a Priority or Interrupt_Priority pragma task_definition]{specified for the Priority or Interrupt_Priority aspect} (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. If no Priority or Interrupt_Priority [pragma applies to]{aspect is specified for} a protected object, the initial priority is specified by the locking policy.

Replace "pragma" by "aspect" in D.3(8/2).

Modify D.3(10/2): If an Interrupt_Handler or Attach_Handler [pragma]{aspect} (see C.3.1) [appears in a protected_definition]{is specified for a protected subprogram of a protected type that does not have the Interrupt_Priority aspect specified}[ without an Interrupt_Priority pragma], the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority.

Replace D.3(11/2): If neither aspect Priority nor Interrupt_Priority is specified for a protected type, and no protected subprogram of the type has aspect Interrupt_Handler or Attach_Handler specified, then the initial priority of the corresponding protected object is System.Priority'Last.

==pragma Relative_Deadline (the pragma is to be obsolescent)

Delete D.2.6(3-6/2) [Now in Annex J.]

Add after D.2.6(9/2):

For a task type (including the anonymous type of a single_task_declaration) or subprogram, the following language-defined representation aspect may be specified:

Relative_Deadline

The value of aspect Relative_Deadline is an expression, which shall be of type Real_Time.Time_Span.

[Editor's Note: See the comment about "single task" in Storage_Size.]

Legality Rules

The Relative_Deadline aspect shall not be specified on a task interface type.

[Editor's note: Task types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from task interfaces (which we don't want to allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).]

Replace D.2.6(12/2):

The Relative_Deadline aspect has no effect if it is specified for a subprogram other than the main subprogram.

Modify D.2.6(13/2):

The initial absolute deadline of a task {for which aspect}[containing pragma] Relative_Deadline {is specified} is the value of Real_Time.Clock + [relative_deadline_]expression{ that is the value of the aspect}, where {this entire expression, including }the call of Real_Time.Clock{, is evaluated} [is made] between task creation and the start of its activation. If {the aspect} [there is no] Relative_Deadline {is not specified}[pragma] then the initial absolute deadline of a task is the value of Default_Deadline. The environment task is also given an initial deadline by this rule{, using the value of the Relative_Deadline aspect of the main subprogram (if any)}.

[Editor's note: The original wording did not specify when the deadline expression is evaluated. Since it is per-object, it also has to be evaluated when the task is created (roughly).]

===pragma CPU (the pragma is to be born obsolescent)

Delete D.16(7-9/3) [Now in Annex J.]

Add after D.16(9/3):

Static Semantics

For a task type (including the anonymous type of a single_task_declaration) or subprogram, the following language-defined representation aspect may be specified:

CPU

The value of aspect CPU is an expression, which shall be of type System.Multiprocessors.CPU_Range.

[Editor's Note: See the comment about "single task" in Storage_Size.]

[Editor's note: Task types cannot be derived, and subprograms never inherit aspects, so we don't have to worry about aspect inheritance, other than from task interfaces (which we don't allow anyway). The inabilility to derive also means we cannot run afoul of 13.1(10).]

Delete D.16(10/3). [Now in Annex J.]

Replace D.16(11/3) with: If the CPU aspect is specified for a subprogram, the expression shall be static.

The CPU aspect shall not be specified on a task interface type.

Modify D.16(12-4/3):

The expression [of a CPU pragma that appears in a task_definition]{specifed for the CPU aspect of a task} is evaluated for each task object (see 9.1). The CPU value is then associated with the task object whose [task_definition contains the pragma]{task declaration specifies the aspect}.

[A CPU pragma]{The CPU aspect} has no effect if it {is specified for a subprogram}[occurs immediately within the declarative_part of a subprogram_body] other than the main subprogram; the CPU value is not associated with any task.

The CPU value is associated with the environment task if [the pragma appears in the declarative_part of]{the CPU aspect is specified for} the main subprogram. If [a pragma CPU does not apply to]{the CPU aspect is not specified for} the main subprogram it is implementation defined on which processor the environment task executes.

===pragma Dispatching_Domain (the pragma is to be born obsolescent)

See AI05-0167-1 for the aspect.

===pragma Implemented (there will not be a pragma)

See AI05-0215-1.

===pragmas Convention, Export, Import: (the pragmas are to be obsolescent)

Rewrite B.1 as follows: [Editor's note: Some parts of this are unchanged.]

B.1 Interfacing Aspects

An /interfacing/ aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention.

Specifying aspect Import to have the value True is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, specifying aspect Export to have the value True is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The Import and Export aspects are intended primarily for objects and subprograms, although implementations are allowed to support other entities. The Link_Name and External_Name aspects are used to specify the link name and external name, respectively, to be used to identify imported or exported entities in the external environment.

The Convention aspect is used to indicate that an Ada entity should use the conventions of another language. It is intended primarily for types and �callback� subprograms. For example, �with Convention => Fortran� on the declaration of an array type Matrix implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order.

A pragma Linker_Options is used to specify the system linker parameters needed when a given compilation unit is included in a partition.

Syntax

The form of a pragma Linker_Options is as follows:

pragma Linker_Options(string_expression);

A pragma Linker_Options is allowed only at the place of a declarative_item.

Name Resolution Rules

The Import and Export aspects are of type Boolean.

The Link_Name and External_Name aspects are of type String.

The expected type for the string_expression in pragma Linker_Options, is String.

Legality Rules

The aspect Convention shall be specified by a /convention_/identifier, which shall be the name of a convention. The convention names are implementation defined, except for certain language-defined ones, such as Ada and Intrinsic, as explained in 6.3.1, �Conformance Rules�. Additional convention names generally represent the calling conventions of foreign languages, language implementations, or specific run-time models. The convention of a callable entity is its calling convention.

If L is a convention_identifier for a language, then a type T is said to be compatible with convention L, (alternatively, is said to be an L-compatible type) if any of the following conditions are met:

T is declared in a language interface package corresponding to L and is defined to be L-compatible (see B.3, B.3.1, B.3.2, B.4, B.5),

Convention L has been specified for T, and T is eligible for convention L; that is:

T is an array type with either an unconstrained or statically-constrained first subtype, and its component type is L-compatible,

T is a record type that has no discriminants and that only has components with statically-constrained subtypes, and each component type is L-compatible,

T is an access-to-object type, its designated type is L-compatible, and its designated subtype is not an unconstrained array subtype,

T is an access-to-subprogram type, and its designated profile's parameter and result types are all L-compatible.

T is derived from an L-compatible type,

The implementation permits T as an L-compatible type.

If the Convention aspect is specified for a type, then the type shall either be compatible with or eligible for the specified convention.

Notwithstanding any rule to the contrary, a declaration with a True Import aspect shall not have a completion.

An entity with a True Import aspect (or Export aspect) is said to be imported (respectively, exported). An entity shall not be both imported and exported.

The declaration of an imported object shall not include an explicit initialization expression. Default initializations are not performed.

The type of an imported or exported object shall be compatible with the specified Convention aspect, if any.

For an imported or exported subprogram, the result and parameter types shall each be compatible with the specified Convention aspect, if any.

The Boolean_expression (if any) used to directly specify an Import or export aspect shall be a static expression. The string_expression used to directly specify an External_Name or Link_Name aspect, and the string_expression of a pragma Linker_Options, shall be static. An External_Name or Link_Name aspect shall be specified only for an entity that is either imported or exported.

Static Semantics

The Convention aspect represents the calling convention or representation convention of the entity. For an access-to-subprogram type, it represents the calling convention of designated subprograms. In addition:

A True Import aspect indicates that the entity is defined externally (that is, outside the Ada program). This aspect is never inherited; if not directly specified, the Import aspect is False.

A True Export aspect indicates that the entity is used externally. This aspect is never inherited; if not directly specified, the Import aspect is False.

For an entity with a True Import or Export aspect, an external name, link name, or both may also be specified.

An external name is a string value for the name used by a foreign language program either for an entity that an Ada program imports, or for referring to an entity that an Ada program exports.

A link name is a string value for the name of an exported or imported entity, based on the conventions of the foreign language's compiler in interfacing with the system's linker tool.

The meaning of link names is implementation defined. If neither a link name nor the Address attribute of an imported or exported entity is specified, then a link name is chosen in an implementation-defined manner, based on the external name if one is specified.

Pragma Linker_Options has the effect of passing its string argument as a parameter to the system linker (if one exists), if the immediately enclosing compilation unit is included in the partition being linked. The interpretation of the string argument, and the way in which the string arguments from multiple Linker_Options pragmas are combined, is implementation defined.

Dynamic Semantics

Notwithstanding what this International Standard says elsewhere, the elaboration of a declaration with a True Import aspect does not create the entity. Such an elaboration has no other effect than to allow the defining name to denote the external entity.

Erroneous Execution

It is the programmer's responsibility to ensure that the use of interfacing aspects does not violate Ada semantics; otherwise, program execution is erroneous.

Implementation Advice

If an implementation supports Export to a given language, then it should also allow the main subprogram to be written in that language. It should support some mechanism for invoking the elaboration of the Ada library units included in the system, and for invoking the finalization of the environment task. On typical systems, the recommended mechanism is to provide two subprograms whose link names are "adainit" and "adafinal". Adainit should contain the elaboration code for library units. Adafinal should contain the finalization code. These subprograms should have no effect the second and subsequent time they are called.

Automatic elaboration of preelaborated packages should be provided when Export is specified.

For each supported convention L other than Intrinsic, an implementation should support Import and Export specification for objects of L-compatible types and for subprograms, and Convention specification for L-eligible types and for subprograms, presuming the other language has corresponding features. Specifying the Convention aspect need not be supported for scalar types.

NOTES

1 Implementations may place restrictions on interfacing aspects; for example, requiring each exported entity to be declared at the library level.

2 The Convention aspect in combination with the Import aspect indicates the conventions for accessing external entities. It is possible that the actual entity is written in assembly language, but reflects the conventions of a particular language. For example, "with Convention => Ada" can be used to interface to an assembly language routine that obeys the Ada compiler's calling conventions.

3 To obtain �call-back� to an Ada subprogram from a foreign language environment, the Convention aspect should be specified both for the access-to-subprogram type and the specific subprogram(s) to which 'Access is applied.

4 It is illegal to specify that both the Import and Export aspects of an entity are true.

6 See also 13.8, �Machine Code Insertions�.

7 If both External_Name and Link_Name are specified for a given entity, then the External_Name is ignored.

Examples

Example of interfacing aspects:

package Fortran_Library is

function Sqrt (X : Float) return Float with Import => True, Convention => Fortran;

function Exp (X : Float) return Float with Import => True, Convention => Fortran;

end Fortran_Library;

In B.3(1/2), B.4(1), and B.5(1) change "the Import, Export and Convention pragmas" to "the Convention aspect" (the aspects Import and Export don't imply a convention). B.4(99), change "pragmas" to "aspects". In B.3(60.13/1), B.3(61/1), B.4(92), and B.5(20) change "pragma Convention" to "the aspect Convention". In B.4(106, 107, 115) and B.5(30), replace the pragmas with equivalent aspects.

Replace B.3(62.1-62.4/3) with:

An implementation need not support specifying the Convention aspect in the following cases: * the Convention aspect specifying convention C for a subprogram that has a parameter of an

unconstrained array subtype, unless the Import aspect has the value True for the subprogram;

* the Convention aspect specifying convention C for a function with an unconstrained array

result subtype;

* the Convention aspect specifying convention C for an object whose nominal subtype is an

unconstrained array subtype.

[Editor's note: None of these cases are types, so I have no idea why C_Pass_By_Copy is mentioned in the original text. (B.3(60.13/1) says C_Pass_By_Copy can only be used on a type.)] [Editor's Note: Need to scrub AARM notes for "pragma Import", "pragma Export", and "pragma Convention". All of the notes in B.1 need to be rewritten, too. Includes B.4(91.j), 6.3.1(11.b), 13.11.2(3.a), 13.7.1(11.a), F.1(2.b)]

In 6.3.1(3/1) and 6.3.1(14), "a pragma" should be "an aspect"; also delete the reference to Import and Export (these are separate aspects from the convention).

In 3.6.2(11), replace "a pragma Convention(Fortran, ...);" with "aspect Convention specifying convention_identifier Fortran".

Delete B.3.2(12); in B.3.2(10-11), add "with Convention => Intrinsic" to each declaration.

In 13.7.2(4), delete the pragmas, in 13.7.2(3), add "with Convention => Intrinsic" to each function.

In 13.7.1(11), delete the pragmas, in 13.7.1(7, 8, 10), add "with Convention => Intrinsic" to each function (7).

In B.2(11.1/2), replace "pragma" by "aspect".

In each of the following paragraphs, replace Pragma Convention (Intrinsic, xxx); with "with Convention => Intrinsic": 13.9(3), 13.11.2(3), 3.9.2(18.2/2), 13.7(14), F.2(6).

Add a new clause to Annex J:

[Note: The subclauses are rearranged in alphabetical order in the core, then for each Annex. Also, these pragmas will be indexed in the pragma Annex L; we don't want people to freak out when they can't find pragma Pack or pragma Inline there (and it will lead them to the right place).]

J.15 Aspect-related Pragmas

Pragmas can be used as an alternative to aspect_specifications to specify certain aspects.

J.15.1 Pragma Inline

Syntax

The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows:

pragma Inline(name {, name});

Legality Rules

The pragma shall apply to one or more callable entities or generic subprograms.

[Editor's Note: "apply" comes from the definition of program unit pragma.

Alternatively, we could have said: "The name of a pragma Inline shall apply to one or more callable entities or generic subprograms that may have aspect Inline specified." which allows us to depend on the Legality Rules of the aspect. In that case, we'd want to swap the Legality Rules and Static Semantics sections. I didn't do this because it is more wordy than just repeating the only Legality Rule of the aspect.]

Static Semantics

Pragma Inline specifies that the Inline aspect (see 6.3.2) for each entity denoted by each name given in the pragma has the value True.

[Editor's note: The following AARM notes are moving from 6.3.2 to here.]

AARM Ramification: Note that inline expansion is desired no matter what name is used in the call. This allows one to request inlining for only one of several overloaded subprograms as follows:

package IO is procedure Put(X : in Integer); procedure Put(X : in String); procedure Put(X : in Character); private procedure Character_Put(X : in Character) renames Put; pragma Inline(Character_Put); end IO;

with IO; use IO; procedure Main is I : Integer; C : Character; begin ... Put(C); -- Inline expansion is desired. Put(I); -- Inline expansion is NOT desired. end Main;

Implementation Permissions

An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

AARM Reason: This is allowed for Ada 83 compatibility. This is only a permission as this usage is considered obsolescent.

AARM Discussion: We only need to allow this in declarative_parts, because a body is only allowed in another body, and these all have declarative_parts.

NOTES

The name in a pragma Inline may denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

J.15.2 Pragma No_Return

Syntax

The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows:

pragma No_Return(procedure_local_name{, procedure_local_name});

Legality Rules

Each procedure_local_name shall denote one or more procedures or generic procedures. [Redundant: The procedure_local_name shall not denote a null procedure nor an instance of a generic unit.]

Static Semantics

Pragma No_Return specifies that the No_Return aspect (see 6.3.2) for each procedure denoted by each local_name given in the pragma has the value True.

J.15.3 Pragma Pack

Syntax

The form of a pragma Pack, which is a representation pragma (see 13.1), is as follows:

pragma Pack(first_subtype_local_name);

Legality Rules

The first_subtype_local_name of a pragma Pack shall denote a composite subtype.

Static Semantics

Pragma Pack specifies that the Pack aspect (see 13.2) for the type denoted by first_subtype_local_name has the value True.

J.15.4 pragma Storage_Size

Syntax

The form of a pragma Storage_Size is as follows:

pragma Storage_Size(expression);

A pragma Storage_Size is allowed only immediately within a task_definition.

Name Resolution Rules

The expression of a pragma Storage_Size is expected to be of any integer type.

Static Semantics

The pragma Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma.

J.15.5 Interfacing pragmas

An interfacing pragma is a representation pragma that is one of the pragmas Import, Export, or Convention. Their forms are as follows:

pragma Import(

[Convention =>] convention_identifier, [Entity =>] local_name

[, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);

pragma Export(

[Convention =>] convention_identifier, [Entity =>] local_name

[, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);

pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);

For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given.

Name Resolution Rules

The expected type for a external_name_string_expression and a link_name_string_expression in an interfacing pragma is String.

Legality Rules

The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).

A pragma Import shall be the completion of a declaration.

The external_name_string_expression and link_name_string_expression of a pragma Import or Export shall be static.

The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

Static Semantics

An interfacing pragam specifies various aspects of the entity denoted by the local_name as follows:

* The Convention aspect (see B.1) is convention_identifier.

* A pragma Import specifies that the Import aspect (see B.1) is True.

* A pragma Export specifies that the Export aspect (see B.1) is True.

* For both pragma Import and Export, if an

external name is given in the pragma, the External_Name aspect is specified to be external_name_string_expression. If a link name is given in the pragma, the Link_Name aspect is specified to be the link_name_string_expression.

J.15.6 Pragma Unchecked_Union

Syntax

The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), is as follows:

pragma Unchecked_Union (first_subtype_local_name);

Legality Rules

The first_subtype_local_name of a pragma Unchecked_Union shall denote an unconstrained discriminated record subtype having a variant_part.

Static Semantics

A pragma Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3) for the type denoted by first_subtype_local_name has the value True.

J.15.7 Pragmas Interrupt_Handler and Attach_Handler

The form of a pragma Interrupt_Handler is as follows:

pragma Interrupt_Handler(handler_name);

The form of a pragma Attach_Handler is as follows:

pragma Attach_Handler(handler_name, expression);

Name Resolution Rules

For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile.

For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2).

Legality Rules

The Attach_Handler and Interrupt_Handler pragmas are only allowed immediately within the protected_definition where the corresponding subprogram is declared. The corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration, and shall not be declared within a generic body. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit.

Static Semantics

For an implementation that supports Annex C, a pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value True. For an implementation that supports Annex C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value of the given expression [Redundant: as evaluated at object creation time].

J.15.8 Shared variable pragmas

Syntax

The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and Volatile_Components, and Independent_Components is as follows:

pragma Atomic(local_name);

pragma Volatile(local_name);

pragma Independent(component_local_name);

pragma Atomic_Components(array_local_name);

pragma Volatile_Components(array_local_name);

pragma Independent_Components(local_name);

Name Resolution Rules

The local_name in an Atomic or Volatile pragma shall resolve to denote either an object_declaration, a non-inherited component_declaration, or a full_type_declaration. The component_local_name in an Independent pragma shall resolve to denote a non-inherited component_declaration. The array_local_name in an Atomic_Components or Volatile_Components pragma shall resolve to denote the declaration of an array type or an array object of an anonymous type. The local_name in an Independent_Components pragma shall resolve to denote the declaration of an array or record type or an array object of an anonymous type.

Static Semantics

These pragmas are representation pragmas (see 13.1). Each of these pragmas specifies that the similarly named aspect (see C.6) of the type, object, or component denoted by its argument is True.

Legality Rules

The local_name of of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

J.15.9 pragma CPU

AARM Discussion: This pragma is born obsolescent; it is defined to provide consistency with existing real-time pragmas.

Syntax

The form of a pragma CPU is as follows:

pragma CPU (expression);

Name Resolution Rules

The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.

Legality Rules

A CPU pragma is allowed only immediately within a task_definition, or the declarative_part of a subprogram_body. At most one such pragma shall appear within a given construct.

For a CPU pragma that appears in the declarative_part of a subprogram_body, the expression shall be static.

Static Semantics

For an implementation that supports Annex D, a pragma CPU specifies the value of the CPU aspect (see D.16). If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma.

[Editor's note: J.15.10 is in AI05-0167-1.]

J.15.11 Pragmas Priority and Interrupt_Priority

Syntax

The form of a pragma Priority is as follows:

pragma Priority(expression);

The form of a pragma Interrupt_Priority is as follows:

pragma Interrupt_Priority[(expression)];

Name Resolution Rules

The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer.

Legality Rules

A Priority pragma is allowed only immediately within a task_definition, a protected_definition, or the declarative_part of a subprogram_body. An Interrupt_Priority pragma is allowed only immediately within a task_definition or a protected_definition. At most one such pragma shall appear within a given construct.

For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority.

Static Semantics

For an implementation that supports Annex D, a pragma Priority specifies the value of the Priority aspect (see D.1) and a pragma Interrupt_Priority specifies the value of the Interrupt_Priority aspect as follows: * If the pragma appears in a task_definition, the expression is associated with

the aspect for the task type or single_task_declaration that contains the pragma;

* If the pragma appears in a protected_definition, the expression is associated

with the aspect for the protected type or single_protected_declaration that contains the pragma;

* If the pragma appears in the declarative part of a subprogram_body, the

expression is associated with the aspect for the subprogram that contains the pragma.

If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last.

J.15.12 pragma Relative_Deadline

Syntax

The form of a pragma Relative_Deadline is as follows:

pragma Relative_Deadline (relative_deadline_expression);

Name Resolution Rules

The expected type for relative_deadline_expression is Real_Time.Time_Span.

Legality Rules

A Relative_Deadline pragma is allowed only immediately within a task_definition or the declarative_part of a subprogram_body. At most one such pragma shall appear within a given construct.

Static Semantics

For an implementation that supports Annex D, a pragma Relative_Deadline specifies the value of the Relative_Deadline aspect (see D.2.6). If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma; otherwise, the expression is associated with the aspect for the subprogram that contains the pragma.

J.15.13 Pragma Asynchronous

Syntax

The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows:

pragma Asynchronous(local_name);

Static Semantics

For an implementation that supports Annex E, a pragma Asynchronous specifies that the Asynchronous aspect (see E.4.1) for the procedure or type denoted by local_name has the value True.

Legality Rules

The local_name of a pragma Asynchronous shall denote a declaration that may have aspect Asynchronous specified.

Rearrange Annex K:

Annex K (informative)

Language-Defined Aspects and Attributes

This annex summarizes the definitions given elsewhere of the language-defined aspects and attributes. Some aspects have corresponding attributes, as noted.

K.1 Language-Defined Aspects

...[etc]

Precondition: Specifies a condition that must hold true in order to call a given subprogram. See 13.3.1.

Size: Size in bits of a subtype or object See 13.3.

K.2 Language-Defined Attributes

...[entire contents of old Annex K goes here.]

!discussion

The intent is that all existing representation and operational aspects can be used in an aspect_specification.

In addition, we would like to allow as many pragmas as possible to be treated as aspects. To make sense as an aspect, a pragma has to be restricted to the scope of the entity.

It has to have two parameters, the first is the entity, the second a name/expression of some type, which is then the type of the aspect.

Or, if the second argument is an "identifier specific to a pragma", it could make sense if we invent "identifiers specific to an aspect". [TBD in AI05-0183-1.]

Or it could have just one parameter, the entity, and the type of the aspect is Boolean (True/False means the pragma is present/absent).

The use of aspects as compared to pragmas is strongly preferred for subprograms (as there are no overloading problems to worry about; the target subprogram is obvious). The use of aspects is also preferred for types and objects, as the pragmas can get separated from the declarations and the declarations are (usually) short. There is no clear-cut decision for aspects applying to packages or other entities.

Since we want to encourage the use of aspects, we make pragmas that can be replaced by aspects obsolescent, with the exception of pragmas that are primarily used on packages.

Following is a list of all Ada pragmas, listed in categories.

----------------

Boolean representation aspects:

pragma Asynchronous(local_name); - See E.4.1.

pragma Atomic(local_name); - See C.6.

pragma Atomic_Components(array_local_name); - See C.6.

pragma Controlled(first_subtype_local_name); - See 13.11.3.

pragma Discard_Names[([On => ] local_name)]; - See C.5.

pragma Independent(component_local_name); - See C.6.

pragma Independent_Components(local_name); - See C.6.

pragma Pack(first_subtype_local_name); - See 13.2.

pragma Volatile(local_name); - See C.6.

pragma Volatile_Components(array_local_name); - See C.6.

pragma Unchecked_Union (first_subtype_local_name); - See B.3.3.

----------------

Pragmas that could be Boolean operational or representation aspects (subject to other concerns):

pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3.

pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1.

pragma Inline(name {, name}); - See 6.3.2.

pragma Interrupt_Handler(handler_name); - See C.3.1.

pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1.

pragma Preelaborable_Initialization(direct_name); - See 10.2.1.

pragma Preelaborate[(library_unit_name)]; - See 10.2.1.

pragma Pure[(library_unit_name)]; - See 10.2.1.

pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3.

pragma Remote_Types[(library_unit_name)]; - See E.2.2.

pragma Shared_Passive[(library_unit_name)]; - See E.2.1.

----------------

Pragmas that could be other (normal) operational or representation aspects:

pragma Attach_Handler(handler_name, expression); - See C.3.1.

-- Aspect type is Interrupts.Interrupt_ID.

pragma CPU (expression); - See D.16.

-- Aspect type is System.Multiprocessors.CPU_Range. -- And this implicitly applies to outer task/prot. or PROCEDURE!

pragma Interrupt_Priority[(expression)]; - See D.1.

-- Aspect type is Integer. -- Does the aspect have a default value? (no.)

pragma Priority(expression); - See D.1.

-- Aspect type is Integer. -- Require static in procedure?

pragma Relative_Deadline (relative_deadline_expression); - See D.2.6.

-- Aspect type is Real_Time.Time_Span.

pragma Storage_Size(expression); - See 13.3.

-- Aspect type is universal_integer?

----------------

Pragmas that could be other (normal) operational or representation aspects using the mechanism for "identifiers specific to an aspect":

pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name); - See B.1.

-- Note that the parameters are backwards

pragma Implemented(procedure_local_name, implementation_kind); - See 9.5 (and AI05-0030-2).

pragma Export(

[Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.

-- Only if split into multiple aspects.

pragma Import(

[Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.

-- Only if split into multiple aspects.

----------------

Make no sense as aspects:

pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2.

pragma Assertion_Policy(policy_identifier); - See 11.4.2.

pragma Detect_Blocking; - See H.5.

pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1.

pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 10.2.1.

pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2.

pragma Linker_Options(string_expression); - See B.1.

pragma List(identifier); - See 2.8.

pragma Locking_Policy(policy_identifier); - See D.3.

pragma Normalize_Scalars; - See H.1.

pragma Optimize(identifier); - See 2.8.

pragma Page; - See 2.8.

pragma Partition_Elaboration_Policy (policy_identifier); - See H.6.

pragma Priority_Specific_Dispatching (

policy_identifier, first_priority_expression, last_priority_expression);

- See D.2.2.

pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13.

pragma Queuing_Policy(policy_identifier); - See D.4.

pragma Restrictions(restriction{, restriction}); - See 13.12.

pragma Reviewable; - See H.3.1.

pragma Suppress(identifier); - See 11.5.

pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2.

pragma Unsuppress(identifier); - See 11.5.

---------------------------

During the discussion of this AI, the question of the value of pragma Controlled came up. As far as we can tell, no implementation supports this pragma and no user uses it other than by mistake (believing it does something it does not).

Beyond that, the name is confusing (as it uses the same term as finalization).

Therefore, we decided to drop this pragma completely (rather than turn it into an aspect).

!corrigendum 2.8(29/2)

Replace the paragraph:

pragma List(Off); -- turn off listing generation pragma Optimize(Off); -- turn off optional optimizations pragma Inline(Set_Mask); -- generate code for Set_Mask inline pragma Import(C, Put_Char, External_Name => "putchar"); -- import C putchar function

by:

pragma List(Off); -- turn off listing generation pragma Optimize(Off); -- turn off optional optimizations pragma Pure(Rational_Numbers); -- set categorization for package pragma Assert(Exists(File_Name), Message =

"Nonexistent file"); -- assert file exists>

!corrigendum 3.7(37/2)

Replace the paragraph:

task type Worker(Prio : System.Priority; Buf : access Buffer) is -- discriminants used to parameterize the task type (see 9.1) pragma Priority(Prio); -- see D.1 entry Fill; entry Drain; end Worker;

by:

task type Worker(Prio : System.Priority; Buf : access Buffer) with Priority =

Prio is -- see D.1 -- discriminants used to parameterize the task type (see 9.1) entry Fill; entry Drain; end Worker;>

!corrigendum 4.8(15)

Replace the paragraph:

27 Implementations are permitted, but not required, to provide garbage collection (see 13.11.3).

by:

27 Implementations are permitted, but not required, to provide garbage collection.

!corrigendum 6.3.2(2)

Delete the paragraph:

The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows:

!corrigendum 6.3.2(3)

Delete the paragraph:

pragma Inline(name {, name});

!corrigendum 6.3.2(4)

Delete the paragraph:

The pragma shall apply to one or more callable entities or generic subprograms.

!corrigendum 6.3.2(5)

Replace the paragraph:

If a pragma Inline applies to a callable entity, this indicates that inline expansion is desired for all calls to that entity. If a pragma Inline applies to a generic subprogram, this indicates that inline expansion is desired for all calls to all instances of that generic subprogram.

by:

For a callable entity or a generic subprogram, the following language-defined representation aspect may be specified:

Inline: The type of aspect Inline is Boolean. When aspect Inline is True for a callable entity, inline expansion is desired for all calls to that entity. When aspect Inline is True for a generic subprogram, inline expansion is desired for all calls to all instances of that generic subprogram.

If directly specified, the aspect_definition shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.

!corrigendum 6.3.2(6)

Replace the paragraph:

For each call, an implementation is free to follow or to ignore the recommendation expressed by the pragma.

by:

For each call, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect.

!corrigendum 6.3.2(6.1/2)

Delete the paragraph:

An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

!corrigendum 6.3.2(7)

Delete the paragraph:

NOTES
The name in a pragma Inline can denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

!corrigendum 6.5.1(0)

Replace the paragraph:

Pragma No_Return

by:

Non-returning Procedures

!corrigendum 6.5.1(1/2)

Replace the paragraph:

A pragma No_Return indicates that a procedure cannot return normally; it may propagate an exception or loop forever.

by:

Specifying aspect No_Return to have the value True indicates that a procedure cannot return normally; it may propagate an exception or loop forever.

!corrigendum 6.5.1(2/2)

Delete the paragraph:

The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows:

!corrigendum 6.5.1(3/2)

Replace the paragraph:

pragma No_Return(procedure_local_name{, procedure_local_name});

by:

Static Semantics

For a procedure or generic procedure, the following language-defined representation aspect may be specified:

No_Return: The type of aspect No_Return is Boolean. When aspect No_Return is True for an entity, the entity is said to be non-returning.

If directly specified, the aspect_definition shall be a static expression. This aspect is never inherited; if not directly specified, the aspect is False.

If a generic procedure is non-returning, then so are its instances. If a procedure declared within a generic unit is non-returning, then so are the corresponding copies of that procedure in instances.

!corrigendum 6.5.1(4/2)

Replace the paragraph:

Each procedure_local_name shall denote one or more procedures or generic procedures; the denoted entities are non-returning. The procedure_local_name shall not denote a null procedure nor an instance of a generic unit.

by:

Aspect No_Return shall not be specified for a null procedure nor an instance of a generic unit.

!corrigendum 6.5.1(8/2)

Delete the paragraph:

!corrigendum 6.5.1(10/2)

Replace the paragraph:

procedure Fail(Msg : String); -- raises Fatal_Error exception pragma No_Return(Fail); -- Inform compiler and reader that procedure never returns normally

by:

procedure Fail(Msg : String) -- raises Fatal_Error exception with No_Return => True; -- Inform compiler and reader that procedure never returns normally

!corrigendum 9.10(1)

!comment This contains the AI-0009-1 and AI-0201-1 changes as well.

@drepl If two different objects, including nonoverlapping parts of the same object, are @i<independently addressable>, they can be manipulated concurrently by two different tasks without synchronization. Normally, any two nonoverlapping objects are independently addressable. However, if packing, record layout, or Component_Size is specified for a given composite object, then it is implementation defined whether or not two nonoverlapping parts of that composite object are independently addressable. @dby If two different objects, including nonoverlapping parts of the same object, are @i<independently addressable>, they can be manipulated concurrently by two different tasks without synchronization. Any two nonoverlapping objects are independently addressable if either object is specified as independently addressable (see C.6). Otherwise, two nonoverlapping objects are independently addressable except when they are both parts of a composite object for which a non-confirming representation item is used to specify record layout, Component_Size, Pack, Atomic, or convention, in which case it is unspecified whether the parts are independently addressable.

!corrigendum 10.1.4(7/2)

Replace the paragraph:

When a compilation unit that declares or renames a library unit is added to the environment, the implementation may remove from the environment any preexisting library_item or subunit with the same full expanded name. When a compilation unit that is a subunit or the body of a library unit is added to the environment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a compilation unit that contains a body_stub is added to the environment, the implementation may remove any preexisting library_item or subunit with the same full expanded name as the body_stub. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically upon the given one. If the given compilation unit contains the body of a subprogram to which a pragma Inline applies, the implementation may also remove any compilation unit containing a call to that subprogram.

by:

When a compilation unit that declares or renames a library unit is added to the environment, the implementation may remove from the environment any preexisting library_item or subunit with the same full expanded name. When a compilation unit that is a subunit or the body of a library unit is added to the environment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a compilation unit that contains a body_stub is added to the environment, the implementation may remove any preexisting library_item or subunit with the same full expanded name as the body_stub. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically upon the given one. If the given compilation unit contains the body of a subprogram for which aspect Inline is True, the implementation may also remove any compilation unit containing a call to that subprogram.

!corrigendum 10.2(15)

Replace the paragraph:

Any included library_unit_declaration to which a pragma Elaborate_Body applies is immediately followed by its library_unit_body, if included.

by:

Any included library_unit_declaration for which aspect Elaborate_Body is True (including when a pragma Elaborate_Body applies) is immediately followed by its library_unit_body, if included.

!corrigendum 10.2.1(25)

Replace the paragraph:

If a pragma Elaborate_Body applies to a declaration, then the declaration requires a completion (a body).

by:

If the aspect Elaborate_Body is True for a declaration (including when pragma Elaborate_Body applies), then the declaration requires a completion (a body).

!corrigendum 10.2.1(26)

Replace the paragraph:

A pragma Elaborate specifies that the body of the named library unit is elaborated before the current library_item. A pragma Elaborate_All specifies that each library_item that is needed by the named library unit declaration is elaborated before the current library_item. A pragma Elaborate_Body specifies that the body of the library unit is elaborated immediately after its declaration.

by:

!corrigendum 11.4.1(4/2)

Replace the paragraph:

procedure Raise_Exception(E : in Exception_Id; Message : in String := ""); pragma No_Return(Raise_Exception); function Exception_Message(X : Exception_Occurrence) return String; procedure Reraise_Occurrence(X : in Exception_Occurrence);

by:

procedure Raise_Exception(E : in Exception_Id; Message : in String := "") with No_Return => True; function Exception_Message(X : Exception_Occurrence) return String; procedure Reraise_Occurrence(X : in Exception_Occurrence);

!corrigendum 11.5(7.2/2)

Replace the paragraph:

If a checking pragma applies to a generic instantiation, then the checking pragma also applies to the instance. If a checking pragma applies to a call to a subprogram that has a pragma Inline applied to it, then the checking pragma also applies to the inlined subprogram body.

by:

If a checking pragma applies to a generic instantiation, then the checking pragma also applies to the instance. If a checking pragma applies to a call to a subprogram for which aspect Inline is True, then the checking pragma also applies to the inlined subprogram body.

!corrigendum 11.6(6)

Replace the paragraph:

If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding exception_handler (or the termination of the task, if none), the external interactions that have occurred need reflect only that the exception was raised somewhere within the execution of the @nt<sequence_of_statements> with the handler (or the task_body), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or independent subprogram that does not dynamically enclose the execution of the construct whose check failed. An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and has no Inline pragma applied to it. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be disrupted by the raising of the exception, causing the object or its parts to become abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.

by:

If an exception is raised due to the failure of a language-defined check, then upon reaching the corresponding exception_handler (or the termination of the task, if none), the external interactions that have occurred need reflect only that the exception was raised somewhere within the execution of the @nt<sequence_of_statements> with the handler (or the task_body), possibly earlier (or later if the interactions are independent of the result of the checked operation) than that defined by the canonical semantics, but not within the execution of some abort-deferred operation or independent subprogram that does not dynamically enclose the execution of the construct whose check failed. An independent subprogram is one that is defined outside the library unit containing the construct whose check failed, and for which the Inline aspect is False. Any assignment that occurred outside of such abort-deferred operations or independent subprograms can be disrupted by the raising of the exception, causing the object or its parts to become abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.

!corrigendum 13.2(0)

Replace the paragraph:

Pragma Pack

by:

Packed Types

!corrigendum 13.2(1)

Replace the paragraph:

A pragma Pack specifies that storage minimization should be the main criterion when selecting the representation of a composite type.

by:

The Pack aspect having the value True specifies that storage minimization should be the main criterion when selecting the representation of a composite type.

!corrigendum 13.2(2)

Delete the paragraph:

The form of a pragma Pack is as follows:

!corrigendum 13.2(3)

Delete the paragraph:

pragma Pack(first_subtype_local_name);

!corrigendum 13.2(4)

Delete the paragraph:

The first_subtype_local_name of a pragma Pack shall denote a composite subtype.

!comment %% 13.2(5) and 13.2(7) need changes here.

!corrigendum 13.3(38)

Replace the paragraph:

5 A component_clause, Component_Size clause, or a pragma Pack can override a specified Alignment.

by:

5 A component_clause, Component_Size clause, or specifying the Pack aspect to True can override a specified Alignment.

!corrigendum 13.3(58)

Replace the paragraph:

7 A component_clause or Component_Size clause can override a specified Size. A pragma Pack cannot.

by:

7 A component_clause or Component_Size clause can override a specified Size. Aspect Pack cannot.

!comment %% 13.3(60), 13.3(61), 13.3(62), 13.3(63), and 13.3(64) need changes here.

!corrigendum 13.3(65)

Replace the paragraph:

Name Resolution Rules

The expression of a pragma Storage_Size is expected to be of any integer type.

by:

Static Semantics

For a task type (including the anonymous type of a single_task_declaration), the following language-defined representation aspect may be specified:

Storage_Size: The value of aspect Storage_Size is an expression, which shall be of any integer type.

Legality Rules

The Storage_Size aspect shall not be specified for a task interface type.

!corrigendum 13.3(66)

Replace the paragraph:

A pragma Storage_Size is elaborated when an object of the type defined by the immediately enclosing task_definition is created. For the elaboration of a pragma Storage_Size, the expression is evaluated; the Storage_Size attribute of the newly created task object is at least the value of the expression.

by:

!corrigendum 13.3(73)

Replace the paragraph:

An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when packing is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation.

by:

An implementation should support specified Component_Sizes that are factors and multiples of the word size. For such Component_Sizes, the array should contain no gaps between components. For other Component_Sizes (if supported), the array should contain no gaps between components when Pack is also specified; the implementation should forbid this combination in cases where it cannot support a no-gaps representation.

!corrigendum 13.3.1(0)

Insert new clause:

Force a conflict; the real text is found in the conflict file.

!corrigendum 13.6(1)

Replace the paragraph:

A type_conversion (see 4.6) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types need to be declared with matching component subtypes, and convertible index types. If one type has packing specified and the other does not, then explicit conversion can be used to pack or unpack an array.

by:

A type_conversion (see 4.6) can be used to convert between two different representations of the same array or record. To convert an array from one representation to another, two array types need to be declared with matching component subtypes, and convertible index types. If one type has Pack specified and the other does not, then explicit conversion can be used to pack or unpack an array.

!corrigendum 13.8(13)

Replace the paragraph:

M : Mask; procedure Set_Mask; pragma Inline(Set_Mask);

by:

M : Mask; procedure Set_Mask with Inline;

!corrigendum 13.11.3(1)

Delete the paragraph:

Pragma Controlled is used to prevent any automatic reclamation of storage (garbage collection) for the objects created by allocators of a given access type.

!corrigendum 13.11.3(2)

Delete the paragraph:

The form of a pragma Controlled is as follows:

!corrigendum 13.11.3(3)

Delete the paragraph:

pragma Controlled(first_subtype_local_name)

!corrigendum 13.11.3(4)

Delete the paragraph:

The first_subtype_local_name of a pragma Controlled shall denote a non-derived access subtype.

!corrigendum 13.11.3(5)

Delete the paragraph:

A pragma Controlled is a representation pragma that specifies the controlled aspect of representation.

!corrigendum 13.11.3(6)

Delete the paragraph:

Garbage collection

is a process that automatically reclaims storage, or moves objects to a different address, while the objects still exist.

!corrigendum 13.11.3(7)

Delete the paragraph:

If a pragma Controlled is specified for an access type with a standard storage pool, then garbage collection is not performed for objects in that pool.

!corrigendum 13.11.3(8)

Delete the paragraph:

An implementation need not support garbage collection, in which case, a pragma Controlled has no effect.

!corrigendum 13.12.1(4/2)

Replace the paragraph:

No_Obsolescent_Features: There is no use of language features defined in Annex J. It is implementation defined whether uses of the renamings of J.1 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.

by:

No_Obsolescent_Features: There is no use of language features defined in Annex J. It is implementation defined whether uses of the renamings of J.1 and of the pragmas of J.15 are detected by this restriction. This restriction applies only to the current compilation or environment, not the entire partition.

!comment %% A.1(37), A.1(42), and A.1(42.1/2) need changes here.

!corrigendum B.1(0)

Replace the paragraph:

Interfacing Pragmas

by:

Interfacing Aspects

!corrigendum B.1(1)

Replace the paragraph:

A pragma Import is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, a pragma Export is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The pragmas Import and Export are intended primarily for objects and subprograms, although implementations are allowed to support other entities.

by:

An interfacing aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention.

!corrigendum B.1(2)

Replace the paragraph:

A pragma Convention is used to specify that an Ada entity should use the conventions of another language. It is intended primarily for types and "callback" subprograms. For example, "pragma Convention(Fortran, Matrix);" implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order.

by:

The Convention aspect is used to indicate that an Ada entity should use the conventions of another language. It is intended primarily for types and "callback" subprograms. For example, "with Convention => Fortran" on the declaration of an array type Matrix implies that Matrix should be represented according to the conventions of the supported Fortran implementation, namely column-major order.

!comment %% B.1(4), B.1(5), B.1(6), B.1(7) and B.1(9.1/1) need changes here.

!corrigendum B.1(10)

Replace the paragraph:

The expected type for a string_expression in an interfacing pragma or in pragma Linker_Options is String.

by:

The Import and Export aspects are of type Boolean.

The Link_Name and External_Name aspects are of type String.

The expected type for the string_expression in pragma Linker_Options, is String.

!comment %% B.1(11), B.1(14), and B.1(21) need changes here.

!comment %% More B.1(xx) need changes here.

!comment %% B.3(23), B.3(33), B.3(34), B.3(39.5/2), B.3(39.6/2), B.3(39.14/2), and B.3(39.15/2) need changes here.

!corrigendum B.3.3(0)

Replace the paragraph:

Pragma Unchecked_Union

by:

Unchecked Union Types

!comment %% B.3.3(1/2), B.3.3(2/2), B.3.3(3/2), B.3.3(4/2), B.3.3(5/2), and B.3.3(6/2) need changes here.

!corrigendum B.3.3(29/2)

Delete the paragraph:

An implementation may require that pragma Controlled be specified for the type of an access subcomponent of an unchecked union type.

!comment %% B.4(12), B.4(16), B.4(20), and B.4(29) need changes here.

!comment %% B.5(12) needs changes here.

!comment %% C.3.1(1), C.3.1(2), C.3.1(3), C.3.1(4), C.3.1(5), and C.3.1(6) need changes here.

!corrigendum C.3.1(7/2)

Replace the paragraph:

The Attach_Handler pragma is only allowed immediately within the protected_definition where the corresponding subprogram is declared. The corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration.

by:

If either the Attach_Hander or Interrupt_Handler aspect are specifed for a protected procedure, the corresponding protected_type_declaration or single_protected_declaration shall be a library-level declaration and shall not be declared within a generic body. In addition to the places where Legality Rules normally apply (see 12.3), this rule also applies in the private part of an instance of a generic unit.

!corrigendum C.3.1(9)

Replace the paragraph:

If the pragma Interrupt_Handler appears in a protected_definition, then the corresponding procedure can be attached dynamically, as a handler, to interrupts (see C.3.2). Such procedures are allowed to be attached to multiple interrupts.

by:

If the Interrupt_Handler aspect of a protected procedure is True, then the procedure may be attached dynamically, as a handler, to interrupts (see C.3.2). Such procedures are allowed to be attached to multiple interrupts.

!corrigendum C.3.1(10)

Replace the paragraph:

The expression in the Attach_Handler pragma as evaluated at object creation time specifies an interrupt. As part of the initialization of that object, if the Attach_Handler pragma is specified, the 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.

by:

The expression specified for the Attach_Handler aspect of a protected procedure P is evaluated as part of the creation of the protected object that contains P. The value of the expression identifies an interrupt. As part of the initialization of that object, P (the handler procedure) is attached to the identified interrupt. A check is made that the corresponding interrupt is not reserved. Program_Error is raised if the check fails, and the existing treatment for the interrupt is not affected.

!corrigendum C.3.1(11/2)

Replace the paragraph:

If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object for which that either an Attach_Handler or Interrupt_Handler pragma applies to one of its procedures, a check is made that the ceiling priority defined in the protected_definition is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised.

by:

If the Ceiling_Locking policy (see D.3) is in effect, then upon the initialization of a protected object that contains a protected procedure for which either the Attach_Handler aspect is specified or the Interrupt_Handler aspect is True, a check is made that the initial ceiling priority of the object is in the range of System.Interrupt_Priority. If the check fails, Program_Error is raised.

!corrigendum C.3.1(12/1)

Replace the paragraph:

When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If an Attach_Handler pragma was used and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored.

by:

When a protected object is finalized, for any of its procedures that are attached to interrupts, the handler is detached. If the handler was attached by a procedure in the Interrupts package or if no user handler was previously attached to the interrupt, the default treatment is restored. If the Attach_Handler aspect was specified and the most recently attached handler for the same interrupt is the same as the one that was attached at the time the protected object was initialized, the previous handler is restored.

!corrigendum C.3.1(14.1/1)

Replace the paragraph:

If the handlers for a given interrupt attached via pragma Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via pragma Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized.

by:

If the handlers for a given interrupt attached via aspect Attach_Handler are not attached and detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when a protected object is finalized, the execution is erroneous if any of the procedures of the protected object are attached to interrupts via aspect Attach_Handler and the most recently attached handler for the same interrupt is not the same as the one that was attached at the time the protected object was initialized.

!corrigendum C.3.1(17)

Replace the paragraph:

When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body.

by:

When the aspects Attach_Handler or Interrupt_Handler are specified for a protected procedure, the implementation is allowed to impose implementation-defined restrictions on the corresponding protected_type_declaration and protected_body.

!corrigendum C.3.1(19)

Replace the paragraph:

Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers.

by:

Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler aspects are allowed to be used for other, implementation defined, forms of interrupt handlers.

!corrigendum C.3.1(22)

Replace the paragraph:

4 The Attach_Handler pragma can provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)

by:

4 The Attach_Handler aspect may provide static attachment of handlers to interrupts if the implementation supports preelaboration of protected objects. (See C.4.)

!corrigendum C.3.2(17)

Replace the paragraph:

The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any existing treatment (including a user handler) in effect for that interrupt. If New_Handler is null, the default treatment is restored. If New_Handler designates a protected procedure to which the pragma Interrupt_Handler does not apply, Program_Error is raised. In this case, the operation does not modify the existing interrupt treatment.

by:

The Attach_Handler procedure attaches the specified handler to the interrupt, overriding any existing treatment (including a user handler) in effect for that interrupt. If New_Handler is null, the default treatment is restored. If New_Handler designates a protected procedure for which the aspect Interrupt_Handler is False, Program_Error is raised. In this case, the operation does not modify the existing interrupt treatment.

!corrigendum C.3.2(21)

Replace the paragraph:

If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt is made to detach a handler that was attached statically (using the pragma Attach_Handler), the handler is not detached and Program_Error is raised.

by:

If, by using the Attach_Handler, Detach_Handler, or Exchange_Handler procedures, an attempt is made to detach a handler that was attached statically (using the aspect Attach_Handler), the handler is not detached and Program_Error is raised.

!corrigendum C.3.2(24)

Replace the paragraph:

If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains either the Attach_Handler or Interrupt_Handler pragmas, but not the Interrupt_Priority pragma. This default need not be the same for all interrupts.

by:

If the Ceiling_Locking policy (see D.3) is in effect, the implementation shall document the default ceiling priority assigned to a protected object that contains a protected procedures that specifies either the Attach_Handler or Interrupt_Handler aspects, but does not specify the Interrupt_Priority aspect. This default need not be the same for all interrupts.

!comment %% C.3.2(28) needs changes here.

!comment %% C.6(21) needs changes here.

!comment %% D.1(2), D.1(3), D.1(4), D.1(5), D.1(6), and D.1(7) need changes here.

!corrigendum D.1(8)

Replace the paragraph:

For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority.

by:

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.

At most one of the Priority and Interrupt_Priority aspects may be specified for a given entity.

Neither of the Priority or Interrupt_Priority aspects shall be specified for a synchronized interface type.

!corrigendum D.1(13)

Delete the paragraph:

The priority specified by a Priority or Interrupt_Priority pragma is the value of the expression in the pragma, if any. If there is no expression in an Interrupt_Priority pragma, the priority value is Interrupt_Priority'Last.

!comment %% D.1(14), D.1(16), D.1(17), D.1(18), and D.1(19) need changes here.

!comment %% D.2.6(2/2), D.2.6(3/2), D.2.6(4/2), D.2.6(5/2), D.2.6(6/2), and D.2.6(9/2) need changes here.

!corrigendum D.2.6(12/2)

Replace the paragraph:

A Relative_Deadline pragma has no effect if it occurs in the declarative_part of the subprogram_body of a subprogram other than the main subprogram.

by:

The Relative_Deadline aspect has no effect if it is specified for a subprogram other than the main subprogram.

!corrigendum D.2.6(13/2)

Replace the paragraph:

The initial absolute deadline of a task containing pragma Relative_Deadline is the value of Real_Time.Clock + relative_deadline_expression, where the call of Real_Time.Clock is made between task creation and the start of its activation. If there is no Relative_Deadline pragma then the initial absolute deadline of a task is the value of Default_Deadline. The environment task is also given an initial deadline by this rule.

by:

The initial absolute deadline of a task for which aspect Relative_Deadline is specified is the value of Real_Time.Clock + the expression that is the value of the aspect, where this entire expression, including the call of Real_Time.Clock, is evaluated between task creation and the start of its activation. If the aspect Relative_Deadline is not specified then the initial absolute deadline of a task is the value of Default_Deadline. The environment task is also given an initial deadline by this rule, using the value of the Relative_Deadline aspect of the main subprogram (if any).

!corrigendum D.3(6.1/2)

Replace the paragraph:

The expression of a Priority or Interrupt_Priority pragma (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. If no Priority or Interrupt_Priority pragma applies to a protected object, the initial priority is specified by the locking policy.

by:

The expression specified for the Priority or Interrupt_Priority aspect (see D.1) is evaluated as part of the creation of the corresponding protected object and converted to the subtype System.Any_Priority or System.Interrupt_Priority, respectively. The value of the expression is the initial priority of the corresponding protected object. If no Priority or Interrupt_Priority aspect is specified for a protected object, the initial priority is specified by the locking policy.

!corrigendum D.3(8/2)

Replace the paragraph:

Every protected object has a ceiling priority, which is determined by either a Priority or Interrupt_Priority pragma as defined in D.1, or by assignment to the Priority attribute as described in D.5.2. The ceiling priority of a protected object (or ceiling, for short) is an upper bound on the active priority a task can have when it calls protected operations of that protected object.

by:

Every protected object has a ceiling priority, which is determined by either a Priority or Interrupt_Priority aspect as defined in D.1, or by assignment to the Priority attribute as described in D.5.2. The ceiling priority of a protected object (or ceiling, for short) is an upper bound on the active priority a task can have when it calls protected operations of that protected object.

!corrigendum D.3(10/2)

Replace the paragraph:

If an Interrupt_Handler or Attach_Handler pragma (see C.3.1) appears in a protected_definition 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.

by:

If an Interrupt_Handler or Attach_Handler aspect (see C.3.1) is specified for a protected subprogram of a protected type that does not have the Interrupt_Priority aspect specified, the initial priority of protected objects of that type is implementation defined, but in the range of the subtype System.Interrupt_Priority.

!corrigendum D.3(11/2)

Replace the paragraph:

If no pragma Priority, Interrupt_Priority, Interrupt_Handler, or Attach_Handler is specified in the protected_definition, then the initial priority of the corresponding protected object is System.Priority'Last.

by:

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.

!corrigendum D.13(5/2)

Replace the paragraph:

Force a conflict;

by:

the real text is found in the conflict file.

!corrigendum D.16(0)

Insert new clause:

Force a conflict; the real text is found in the conflict file.

!corrigendum E.2.3(13/1)

Replace the paragraph:

it shall not be, nor shall its visible part contain, the declaration of a subprogram to which a pragma Inline applies;

by:

it shall not be, nor shall its visible part contain, the declaration of a subprogram for which aspect Inline is True;

!corrigendum E.2.3(16)

Replace the paragraph:

If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call interface.

by:

!corrigendum E.2.3(19/1)

Replace the paragraph:

If a pragma All_Calls_Remote applies to a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit package from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the unit package are defined to be local and shall not go through the PCS.

by:

If aspect All_Calls_Remote is True for a given RCI library unit, then the implementation shall route any call to a subprogram of the RCI unit package from outside the declarative region of the unit through the Partition Communication Subsystem (PCS); see E.5. Calls to such subprograms from within the declarative region of the unit package are defined to be local and shall not go through the PCS.

!corrigendum E.4.1(0)

Replace the paragraph:

Pragma Asynchronous

by:

Asynchronous Remote Subprograms

!corrigendum E.4.1(1)

Replace the paragraph:

This subclause introduces the pragma Asynchronous which allows a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body.

by:

This subclause introduces the aspect Asynchronous which can be specified to allow a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body.

!comment %% E.4.1(2), E.4.1(3), E.4.1(4), E.4.1(5), and E.4.1(6) need to be deleted here.

!corrigendum E.4.1(7)

Delete the paragraph:

The first subtype of a remote access-to-class-wide type.

!corrigendum E.4.1(8)

Replace the paragraph:

A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the type-related asynchronous aspect of the type.

by:

For a remote procedure, the following language-defined representation aspect may be specified:

Asynchronous: The type of aspect Asynchronous is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified, the aspect is False.

For a remote access type, the following language-defined representation aspect may be specified:

Asynchronous: The type of aspect Asynchronous is Boolean. If directly specified, the aspect_definition shall be a static expression. If not specified (including by inheritance), the aspect is False.

Legality Rules

If aspect Asynchronous is specified for a remote procedure, the formal parameters of the procedure shall all be of mode in.

!corrigendum E.4.1(9)

Replace the paragraph:

A remote call is asynchronous if it is a call to a procedure, or a call through a value of an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma Asynchronous applies to a remote access-to-class-wide type, then a dispatching call on a procedure with a controlling operand designated by a value of the type is asynchronous if the formal parameters of the procedure are all of mode in.

by:

A remote call is asynchronous if it is a call to a procedure, or a call through a value of an access-to-procedure type, for which aspect Asynchronous is True. In addition, if aspect Asynchronous is True for a remote access-to-class-wide type, then a dispatching call on a procedure with a controlling operand designated by a value of the type is asynchronous if the formal parameters of the procedure are all of mode in.

!corrigendum J.15(0)

Insert new clause:

Pragmas can be used as an alternative to aspect_specifications to specify certain aspects.

!corrigendum J.15.1(0)

Insert new clause:

Syntax

The form of a pragma Inline, which is a program unit pragma (see 10.1.5), is as follows:

pragma Inline(name {, name});

Legality Rules

The pragma shall apply to one or more callable entities or generic subprograms.

Static Semantics Pragma

Inline specifies that the Inline aspect (see 6.3.2) for each entity denoted by each name given in the pragma has the value True.

Implementation Permissions

An implementation may allow a pragma Inline that has an argument which is a direct_name denoting a subprogram_body of the same declarative_part.

NOTES
The name in a pragma Inline may denote more than one entity in the case of overloading. Such a pragma applies to all of the denoted entities.

!corrigendum J.15.2(0)

Insert new clause:

Syntax

The form of a pragma No_Return, which is a representation pragma (see 13.1), is as follows:

pragma No_Return(procedure_local_name{, procedure_local_name});

Legality Rules

Each procedure_local_name shall denote one or more procedures or generic procedures. The procedure_local_name shall not denote a null procedure nor an instance of a generic unit.

Static Semantics Pragma

No_Return specifies that the No_Return aspect (see 6.3.2) for each procedure denoted by each local_name given in the pragma has the value True.

!corrigendum J.15.3(0)

Insert new clause:

Syntax

The form of a pragma Pack, which is a representation pragma (see 13.1), is as follows:

pragma Pack(first_subtype_local_name);

Legality Rules

The first_subtype_local_name of a pragma Pack shall denote a composite subtype.

Static Semantics Pragma

Pack specifies that the Pack aspect (see 13.2) for the type denoted by first_subtype_local_name has the value True.

!corrigendum J.15.4(0)

Insert new clause:

Syntax

The form of a pragma Storage_Size is as follows:

pragma Storage_Size(expression);

A pragma Storage_Size is allowed only immediately within a task_definition.

Name Resolution Rules

The expression of a pragma Storage_Size is expected to be of any integer type.

Static Semantics

The pragma Storage_Size sets the Storage_Size aspect (see 13.3) of the type defined by the immediately enclosing task_definition to the value of the expression of the pragma.

!corrigendum J.15.5(0)

Insert new clause:

Syntax

An interfacing pragma is a representation pragma that is one of the pragmas Import, Export, or Convention. Their forms are as follows:

pragma Import(
[Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);

pragma Export(
[Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);

pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);

For pragmas Import and Export, the argument for Link_Name shall not be given without the pragma_argument_identifier unless the argument for External_Name is given.

Name Resolution Rules

The expected type for a external_name_string_expression and a link_name_string_expression in an interfacing pragma is String.

Legality Rules

The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).

A pragma Import shall be the completion of a declaration.

The external_name_string_expression and link_name_string_expression of a pragma Import or Export shall be static.

The local_name of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

Static Semantics

An interfacing pragma specifies various aspects of the entity denoted by the local_name as follows:

The Convention aspect (see B.1) is convention_identifier.

A pragma Import specifies that the Import aspect (see B.1) is True.

A pragma Export specifies that the Export aspect (see B.1) is True.

For both pragma Import and Export, if an external name is given in the pragma, the External_Name aspect (see B.1) is specified to be external_name_string_expression. If a link name is given in the pragma, the Link_Name aspect (see B.1) is specified to be the link_name_string_expression.

!corrigendum J.15.6(0)

Insert new clause:

Syntax

The form of a pragma Unchecked_Union, which is a representation pragma (see 13.1), is as follows:

pragma Unchecked_Union (first_subtype_local_name);

Legality Rules

The first_subtype_local_name of a pragma Unchecked_Union shall denote an unconstrained discriminated record subtype having a variant_part.

Static Semantics

A pragma Unchecked_Union specifies that the Unchecked_Union aspect (see B.3.3) for the type denoted by first_subtype_local_name has the value True.

!corrigendum J.15.7(0)

Insert new clause:

The form of a pragma Interrupt_Handler is as follows:

pragma Interrupt_Handler(handler_name);

The form of a pragma Attach_Handler is as follows:

pragma Attach_Handler(handler_name, expression);

Name Resolution Rules

For the Interrupt_Handler and Attach_Handler pragmas, the handler_name shall resolve to denote a protected procedure with a parameterless profile.

For the Attach_Handler pragma, the expected type for the expression is Interrupts.Interrupt_Id (see C.3.2).

Legality Rules

Static Semantics

For an implementation that supports Annex C, a pragma Interrupt_Handler specifies the Interrupt_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value True. For an implementation that supports Annex C, a pragma Attach_Handler specifies the Attach_Handler aspect (see C.3.1) for the protected procedure handler_name to have the value of the given expression as evaluated at object creation time.

!corrigendum J.15.8

Insert new clause:

Syntax

The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and Volatile_Components, and Independent_Components is as follows:

pragma Atomic(local_Name);

pragma Volatile(local_Name);

pragma Atomic(component_local_Name);

pragma Atomic_Components(array_local_Name);

pragma Volatile_Components(array_local_Name);

pragma Independent_Components(local_Name);

Name Resolution Rules

The local_name in an Atomic or Volatile pragma shall resolve to denote either an object_declaration, a non-inherited component_declaration, or a full_type_declaration. The component_local_name in an Independent pragma shall resolve to denote a non-inherited component_declaration. The array_local_name in an Atomic_Components or Volatile_Components pragma shall resolve to denote the declaration of an array type or an array object of an anonymous type. The local_name in an Independent_Components pragma shall resolve to denote the declaration of an array or record type or an array object of an anonymous type.

Static Semantics

These pragmas are representation pragmas (see 13.1). Each of these pragmas specifies that the similarly named aspect (see C.6) of the type, object, or component denoted by its argument is True.

Legality Rules

The local_name of of each of these pragmas shall denote a declaration that may have the similarly named aspect specified.

!corrigendum J.15.9

Insert new clause:

Syntax

The form of a pragma CPU is as follows:

pragma CPU(expression);

Name Resolution Rules

The expected type for the expression of a pragma CPU is System.Multiprocessors.CPU_Range.

Legality Rules

A CPU pragma is allowed only immediately within a task_definition, or the declarative_part of a subprogram_body. At most one such pragma shall appear within a given construct.

For a CPU pragma that appears in the declarative_part of a subprogram_body, the expression shall be static.

Static Semantics

!comment J.15.10 is in AI05-0167-1.

!corrigendum J.15.11

Syntax

The form of a pragma Priority is as follows:

pragma Priority(expression);

The form of a pragma Interrupt_Priority is as follows:

pragma Interrupt_Priority[(expression)];

Name Resolution Rules

The expected type for the expression in a Priority or Interrupt_Priority pragma is Integer.

Legality Rules

For a Priority pragma that appears in the declarative_part of a subprogram_body, the expression shall be static, and its value shall be in the range of System.Priority.

Static Semantics

If the pragma appears in a task_definition, the expression is associated with the aspect for the task type or single_task_declaration that contains the pragma;

If the pragma appears in a protected_definition, the expression is associated with the aspect for the protected type or single_protected_declaration that contains the pragma;

If the pragma appears in the declarative_part of a subprogram_body, the expression is associated with the aspect for the subprogram that contains the pragma.

If there is no expression in an Interrupt_Priority pragma, the Interrupt_Priority aspect has the value Interrupt_Priority'Last.

!corrigendum J.15.12

Insert new clause:

Syntax

The form of a pragma Relative_Deadline is as follows:

pragma Relative_Deadline (relative_deadline_expression);

Name Resolution Rules

The expected type for a relative_deadline_expression is Real_Time.Time_Span.

Legality Rules

A Relative_Deadline pragma is allowed only immediately within a task_definition or the declarative_part of a subprogram_body. At most one such pragma shall appear within a given construct.

Static Semantics

!corrigendum J.15.13

Insert new clause:

Syntax

The form of a pragma Asynchronous, which is a representation pragma (see 13.1), is as follows:

pragma Asynchronous(local_name);

Static Semantics

For an implementation that supports Annex E, a pragma Asynchronous specifies that the Asynchronous aspect (see E.4.1) for the procedure or type denoted by local_name has the value True.

Legality Rules

The local_name of a pragma Asynchronous shall denote a declaration that may have aspect Asynchronous specified.

!ACATS test

ACATS tests would be needed to check that all of these aspects can be specified.

!appendix

From: Bob Duff
Sent: Monday, October 25, 2010  2:44 PM

From the Valencia minutes:

  New Action Items
...
  Bob Duff
...
  AI to add wording to explain which non-attribute aspects can be specified via
  aspect clauses, and the exact semantics for such specification. (See discussion
  of AI05-0183-1.)  Participate in the amendment subcommittee ...
  ----------------

  Tucker would like to make a separate AI to handle changes to individual
  aspects. But add a general statement about specifiable attributes in this AI.

  Wording needs to be added to 13.1(9-9.1) to include aspect clauses (to prevent
  specifying one aspect in multiple ways).

  Tucker says that he tried to use some common wording in AI-139-2, 4.1.6.

  This would then be used to create an annex similar to the attribute one.

  We are electing Bob to do this new AI, using the AI05-0139-2 wording as a
  model. He will need to A,"fixA," the wording from AI05-0145-2 into this
  format. [Editor's note: I did this for the wording proposed for AI05-0146-1 and
  in these minutes for AI05-0153-1].

Randy explained the above privately:

> We want the AI which defines which aspects can be specified with the
> AI-183 to be separate from AI-183, because it is likely to be large
> and it would obscure the more complex wording.

OK.  I've included some wording below.  I think I may be misunderstanding what
you want, because it's not all that large.  If you have in mind rewriting all
the rules for every sort of attribute_definition_clause, then, well... That's
NUTS!

If this job entails rewriting all of chap 13 (again!) plus a bunch of other
stuff, then I think we should back off.  It is REALLY not important to allow
"Foo with Bar => Baz" when there's already a way to say it.

> AI-139-2 defines a couple of aspects in a format that Tucker is
> proposing be used for *all* specifiable aspects. You can use that as a
> model (or AI-146 or AI-153-1 as I already modified them to use that same
> format).

OK, and as clarified by Tucker privately, some aspects are also attributes, some
are also pragmas, and some are just aspects.

> We expect that all specifable attributes will be usable as aspects in
> aspect clauses in the same way as they can be used in attribute
> clauses (that will reduce the needed wording). But we also need
> wording for every pragma that can be used as an aspect: probably Pack,
> the ones in C.6, Priority, CPU (which is new),...

If CPU is new, we could get rid of the pragma, and just make it an aspect. The
whole point of aspect_specifications (25 years too late) is to reduce the
proliferation of pragmas, each with its own distinct rules.

>... etc. Robert had suggested that Pack => False turn off  packing (not
>sure if that introduces new problems, it definitely would for  Atomic).
>You'll need to decide if that makes sense.

I'm not sure I like the idea of Pack => False.  It seems like a neat feature in
isolation, but if it requires hard thinking about Atomic and friends, I'm not
sure it's worth the trouble.

----------------

I've no idea where the following wording belongs.  I'm still not sure exactly
what's wanted, so I'm sending this trial baloon to see if it floats.

The following aspects may be used as an aspect_mark:

    - Each specifiable attribute may be specified by an
      attribute_definition_clause, as explained in 13.3, or by an
      aspect_specification, with the same semantics.

    - A representation pragma that has a single argument that is a local_name
      may be specified by an aspect_specification, with the entity being the
      local_name, the aspect_mark being the same as the pragma name.  The
      aspect_definition is expected to be of type Boolean. The expression shall
      be static with value True.

    - Additional aspects that are neither attributes nor pragmas are defined
      throughout this International Standard.

AARM Discussion:

   The following representation pragmas may also be specified using an
   aspect_specification:

      Asynchronous   E.4.1(8)
      Atomic   C.6(14)
      Atomic_Components   C.6(14)
      Controlled   13.11.3(5)
      Discard_Names   C.5(6)
      Independent   C.6(14)
      Independent_Components   C.6(14)
      Pack   13.2(5)
      Volatile   C.6(14)
      Volatile_Components   C.6(14)
      Unchecked_Union

   The following representation pragmas cannot be specified using an
   aspect_specification, because the pragma arguments wouldn't make
   sense as an aspect_definition:

      CPU ???
      Convention   B.1(28)
      Export   B.1(28)
      Import   B.1(28)

End AARM Discussion.

(Seems like the above should be part of AI05-0183-1.
I can understand why you might want the stuff below in a separate AI.)

Change "packing" to "Pack" in numerous (but not all) places.  E.g. 9.10(1/3).

Remove all wording for representation pragmas that says this pragma specifies
so-and-so aspect:

13.2(5):
5     [A pragma Pack specifies the packing aspect of representation; ] {If Pack
      is specified, } the type (or the extension part) is said to be packed. For
      a type extension, the parent part is packed as for the parent type, and a
      pragma Pack causes packing only of the extension part.

13.11.3(5):
5     A pragma Controlled is a representation pragma[ that specifies the
controlled aspect of representation].

B.3.3(4/2):
4/2   Unchecked_Union is a representation pragma[, specifying the unchecked
union aspect of representation].

C.5(6): No changes needed for Discard_Names.

C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
	 Independent_Components, Volatile, Volatile_Components.

E.4.1(8):
8     A pragma Asynchronous is a representation pragma.[ When applied to a
type, it specifies the type-related asynchronous aspect of the type.]

Add Unchecked_Union to the index under "representation pragma".

****************************************************************

From: Tucker Taft
Sent: Monday, October 25, 2010  3:10 PM

I am interpreting the "[]" as deletions, rather than indicating as redundant.
Also, I notice you eliminated the mention that the asynchronous aspect was
"type-related." I think we want to preserve the distinction between type-related
and subtype-specific aspects.  That may affect the legality of specifying the
aspect on a subtype declaration.  So we should be careful about deleting phrases
that include "type-related" or "subtype-specific" unless they show up elsewhere.

****************************************************************

From: Bob Duff
Sent: Monday, October 25, 2010  5:51 PM

> I am interpreting the "[]" as deletions, rather than indicating as
> redundant.

Right.  I get mixed up between {} and [].  I think the convention for AI's is {}
for insertions, [] for deletions, and Redundant[] for redundancies.  The
convention in the AARM is [] for redundancies.  The convention in the RM is to
have no such noise.

Please correct me if I'm wrong.

>...Also, I notice you eliminated
> the mention that the asynchronous aspect was "type-related."

So I guess it should be:

E.4.1(8):
8     A pragma Asynchronous is a representation pragma.[ When applied to a type,
it specifies the type-related asynchronous aspect of the type.] The Asynchronous
aspect is type-related when applied to a type.

****************************************************************

From: Randy Brukardt
Sent: Monday, October 25, 2010  6:15 PM

> Right.  I get mixed up between {} and [].  I think the convention for
> AI's is {} for insertions, [] for deletions, and Redundant[] for
> redundancies.  The convention in the AARM is [] for redundancies.  The
> convention in the RM is to have no such noise.
>
> Please correct me if I'm wrong.

That is exactly right.

****************************************************************

From: Randy Brukardt
Sent: Monday, October 25, 2010  6:42 PM

...
> I've no idea where the following wording belongs.  I'm still not sure
> exactly what's wanted, so I'm sending this trial baloon to see if it
> floats.

I think it is pretty close.

We also need text to introduce the "aspect annex" (the intent is that we will
have an annex similar to the attribute one that shows all of the possible
aspects). The actual annex will be automatically created somehow.

CPU and Priority don't have local names, but they ought to be specifable as
aspects. (At least, we ought to consider that!)

I'm not sure that Unchecked_Union makes sense here (it's closer to pragma
Convention than to the others on this list).

I suspect it would be best with the pragmas to simply list the ones that are
included (then we don't need to come up with a blanket rule that isn't really
quite what we want).

****************************************************************

From: Bob Duff
Sent: Saturday, October 30, 2010  1:00 PM

More info on AI05-0229-1, Specifiable aspects.
I tried to study all the pragmas (from Annex L), and see if they make sense as
"aspects".

----------------

To make sense as an aspect, the pragma has to be restricted to the scope of the
entity.

It has to have two parameters, the first is the entity, the second a
name/expression of some type, which is then the type of the aspect.

Or, if the second argument is an "identifier specific to a pragma", it could
make sense if we invent "identifiers specific to an aspect".  Tucker said he'd
work on that.

Or it could have just one parameter, the entity, and the type of the aspect is
Boolean (True/False means the pragma is present/absent).

----------------

Boolean representation attributes already discussed:

3     pragma Asynchronous(local_name); - See E.4.1.

4     pragma Atomic(local_name); - See C.6.

5     pragma Atomic_Components(array_local_name); - See C.6.

7     pragma Controlled(first_subtype_local_name); - See 13.11.3.

9     pragma Discard_Names[([On => ] local_name)]; - See C.5.

14.1/3 pragma Independent(component_local_name); - See C.6.

14.2/3 pragma Independent_Components(local_name); - See C.6.

24    pragma Pack(first_subtype_local_name); - See 13.2.

38    pragma Volatile(local_name); - See C.6.

39    pragma Volatile_Components(array_local_name); - See C.6.

37.1/2 pragma Unchecked_Union (first_subtype_local_name); - See B.3.3.

----------------

More Boolean aspects:

2     pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3.

12    pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1.

15    pragma Inline(name {, name}); - See 6.3.2.

17    pragma Interrupt_Handler(handler_name); - See C.3.1.

21.1/2 pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1.

25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1.

26    pragma Preelaborate[(library_unit_name)]; - See 10.2.1.

28    pragma Pure[(library_unit_name)]; - See 10.2.1.

30    pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3.

31    pragma Remote_Types[(library_unit_name)]; - See E.2.2.

34    pragma Shared_Passive[(library_unit_name)]; - See E.2.1.

----------------

Non-Boolean aspects:

6     pragma Attach_Handler(handler_name, expression); - See C.3.1.
                -- Aspect type is Interrupts.Interrupt_ID.

8.1/3 pragma CPU (expression); - See D.16.
                -- Aspect type is System.Multiprocessors.CPU_Range.
And this implicitly applies to outer task/prot.
Or PROCEDURE!

18    pragma Interrupt_Priority[(expression)]; - See D.1.
                -- Aspect type is Integer.
Does aspect have a default?

27    pragma Priority(expression); - See D.1.
                -- Aspect type is Integer.
Require static in procedure?

29.1/2 pragma Relative_Deadline (relative_deadline_expression); - See D.2.6.
                -- Aspect type is Real_Time.Time_Span.

35    pragma Storage_Size(expression); - See 13.3.
                -- Aspect type is universal_integer?

----------------

"identifiers specific to an aspect":

8     pragma Convention([Convention =>] convention_identifier,[Entity =>]
local_name); - See B.1.
(except the parameters are backwards)

13.1/2 pragma Implemented(procedure_local_name, implementation_kind); - See 9.5.

----------------

Make no sense as aspects:

2.1/2 pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2.

2.2/2 pragma Assertion_Policy(policy_identifier); - See 11.4.2.

8.2/2 pragma Detect_Blocking; - See H.5.

10    pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1.

11    pragma Elaborate_All(library_unit_name{, library_unit_name}); - See
10.2.1.

13    pragma Export(
     [Convention =>] convention_identifier, [Entity =>] local_name
  [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.

14    pragma Import(
     [Convention =>] convention_identifier, [Entity =>] local_name
  [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1.

16    pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2.

19    pragma Linker_Options(string_expression); - See B.1.

20    pragma List(identifier); - See 2.8.

21    pragma Locking_Policy(policy_identifier); - See D.3.

22    pragma Normalize_Scalars; - See H.1.

23    pragma Optimize(identifier); - See 2.8.

25    pragma Page; - See 2.8.

25.1/2 pragma Partition_Elaboration_Policy (policy_identifier); - See H.6.

27.1/2 pragma Priority_Specific_Dispatching (
     policy_identifier, first_priority_expression, last_priority_expression);
- See D.2.2.

27.2/2 pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13.

29    pragma Queuing_Policy(policy_identifier); - See D.4.

32    pragma Restrictions(restriction{, restriction}); - See 13.12.

33    pragma Reviewable; - See H.3.1.

36    pragma Suppress(identifier); - See 11.5.

37    pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2.

37.2/2 pragma Unsuppress(identifier); - See 11.5.

----------------

****************************************************************

From: Robert Dewar
Sent: Saturday, October 30, 2010  1:12 PM

> More info on AI05-0229-1, Specifiable aspects.
> I tried to study all the pragmas (from Annex L), and see if they make
> sense as "aspects".

> 25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1.
>
> 26    pragma Preelaborate[(library_unit_name)]; - See 10.2.1.
>
> 28    pragma Pure[(library_unit_name)]; - See 10.2.1.
>
> 30    pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3.
>
> 31    pragma Remote_Types[(library_unit_name)]; - See E.2.2.
>
> 34    pragma Shared_Passive[(library_unit_name)]; - See E.2.1.

The library unit ones make no sense to me, it is obviously inferior to have
these at the end of the unit instead of the start as wouldl be forced by use of
aspects.

Just for reference, the current GNAT list is:

>       Aspect_Address,
>       Aspect_Alignment,
>       Aspect_Bit_Order,
>       Aspect_Component_Size,
>       Aspect_Dynamic_Predicate,
>       Aspect_External_Tag,
>       Aspect_Input,
>       Aspect_Invariant,
>       Aspect_Machine_Radix,
>       Aspect_Object_Size,                   -- GNAT
>       Aspect_Output,
>       Aspect_Post,
>       Aspect_Pre,
>       Aspect_Predicate,                     -- GNAT
>       Aspect_Read,
>       Aspect_Size,
>       Aspect_Static_Predicate,
>       Aspect_Storage_Pool,
>       Aspect_Storage_Size,
>       Aspect_Stream_Size,
>       Aspect_Suppress,
>       Aspect_Unsuppress,
>       Aspect_Value_Size,                    -- GNAT
>       Aspect_Warnings,
>       Aspect_Write,
>
>       --  Remaining aspects have a static boolean value that turns the aspect
>       --  on or off. They all correspond to pragmas, and the flag Aspect_Cancel
>       --  is set on the pragma if the corresponding aspect is False.
>
>       Aspect_Ada_2005,                      -- GNAT
>       Aspect_Ada_2012,                      -- GNAT
>       Aspect_Atomic,
>       Aspect_Atomic_Components,
>       Aspect_Discard_Names,
>       Aspect_Favor_Top_Level,               -- GNAT
>       Aspect_Inline,
>       Aspect_Inline_Always,                 -- GNAT
>       Aspect_No_Return,
>       Aspect_Pack,
>       Aspect_Persistent_BSS,                -- GNAT
>       Aspect_Preelaborable_Initialization,
>       Aspect_Pure_Function,                 -- GNAT
>       Aspect_Shared,                        -- GNAT (equivalent to Atomic)
>       Aspect_Suppress_Debug_Info,           -- GNAT
>       Aspect_Unchecked_Union,
>       Aspect_Universal_Aliasing,            -- GNAT
>       Aspect_Unmodified,                    -- GNAT
>       Aspect_Unreferenced,                  -- GNAT
>       Aspect_Unreferenced_Objects,          -- GNAT
>       Aspect_Volatile,
>       Aspect_Volatile_Components);

****************************************************************

From: Bob Duff
Sent: Saturday, October 30, 2010  6:17 PM

> The library unit ones make no sense to me, it is obviously inferior to
> have these at the end of the unit instead of the start as wouldl be
> forced by use of aspects.

I wonder if you implemented the right syntax, as specified by the latest version
of AI-183.  It's something like

    package P with Elaborate_Body => True is
        ...
    end P;

This stuff is a moving target -- we keep changing various aspect names, etc.

> Just for reference, the current GNAT list is:

I haven't had time to compare your list to mine.
All I know is, there seems to be pressure from everyone to make everything under
the sun into an "aspect". I've no objection to that when it's easy, but a lot of
these pragmas have all kinds of strange warts that require thinking about -- and
RM wording -- that I'd like to avoid.

My previous e-mail is an attempt to list out all pragmas that are remotely
possible as aspects.

****************************************************************

From: Robert Dewar
Sent: Saturday, October 30, 2010  6:32 PM

> I wonder if you implemented the right syntax, as specified by the
> latest version of AI-183.  It's something like
>
>      package P with Elaborate_Body =>  True is
>          ...
>      end P;

No, that's new, but why it is somehow preferable to

        package P is
           pragma Elaborate_Body;
             ...
        end P;

when it is more tokens beats me, well we will eventually get these unimportant
ones picked up when we figure what they are. This particular one is annoying
since it is a special case (no semicolon after the aspect list).

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  10:07 AM

I think it is a good idea to have aspects for library unit pragmas, since it is
always nicer to do things with proper syntax than pragmas when the result has
significant semantic impact, so I prefer

      package X with Pure is

to

      package X is pragma Pure;

BUT, if we allow a Boolean parameter

      package X with Pure => True is ...

then we need special rules, we can't delay the evaluation of True until X is
frozen, so I think for such pragmas we shouldn't delay the evaluation of the
expression!

Actually, I would suggest that, assuming we keep the boolean expression for the
boolean cases, with the possibility of False meaning, forget about the aspect
entirely (remove the awkward cancellation semantics for the derived type case),
then I think we should evaluate the boolean parameter immediately always.

It is just silly to allow

      type R is array ... with
        Packed => True;

      ...

      True : Boolean := False;

and if you are using this in a reasonable way to parametrize whether R should be
packed, then it is perfectly reasonable for the boolean case to say that you
refer to a previously set configuration, something like

     type R is array ... with
       Packed => Pack_If_Space_Optimizing;

where Pack_If_Space_Optimizing is some global constant

(off topic, I have often thought it would be useful to be able to define such
global constants in the configuration pragma file, to avoid the need for a
million with's :-))

****************************************************************

From: Tucker Taft
Sent: Monday, November 1, 2010  10:34 AM

I think we still want to defer resolution of pragmas that apply to packages.  We
had proposed the notion of a Package_Invariant at one point.  That would almost
certainly be an expression that would be boolean, and would involve calling a
function declared later inside the package.  So I am not sure I see the value
nor the need to have different rules for aspects that apply to packages, nor for
aspects that happen to be boolean.

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  11:03 AM

> I think we still want to defer resolution of pragmas that apply to
> packages.  We had proposed the notion of a Package_Invariant at one
> point.  That would almost certainly be an expression that would be
> boolean, and would involve calling a function declared later inside
> the package.  So I am not sure I see the value nor the need to have
> different rules for aspects that apply to packages, nor for aspects
> that happen to be boolean.

Well this is a case where the compiler is totally unprepared to deal with the
equivalent of a pragma Pure appearing at the end of the package. This would be a
major earthquake. We check the status of such things as we analyze the
declarations of the package, anything else would be huge extra work for almost
NO gain, since for something like Pure, being able to defer whether the package
is Pure till the end of the package is pretty absurd. Also, how about

      package P with Pure => Pure_OK is
         ...
         Pure_OK : constant Boolean := False;
         ...
      end;

Now we have the anomoly that if the package is pure, then the declaration is
illegal, and cannot affect the legality of the rest of the package, but if it is
not pure, then the declaration is OK, and since it indeed False and the package
is not Pure.

My suggestion applies ONLY to aspects where we require a static Boolean value
(e.g. Pack, Pure etc).

Of course it does not apply to any situation where we have a general boolean
expression.

The cases of static boolean values being required for binary aspects that are on
(True) or off (False) are really are quite different.

If we allow an expression here at all is a matter of debate,

if we allow it, allowing False is a matter of debate.

But surely delaying the evaluation in such a case is NOT useful, it allows only
stupid useless tests at the expense (if applied to pragmas that normally could
not be themselves delayed) of huge extra work in the compiler.

****************************************************************

From: John Barnes
Sent: Monday, November 1, 2010  11:04 AM

I haven't really been following this because of being poorly. But I think pragma
Pure is fine as it is; I wouldn't want to write.

package Ada with Pure is end Ada;

Horrid.

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  11:11 AM

For me

   package Ada with Pure => True is
   end Ada;

is better than

   package Ada is
     pragma Pure;
   end Ada;

because I don't like pragmas having a big effect on legality like this. Better
done with syntax.

Note the pragma is still there, so if this is just asthetics on your part (note
for me there is a real principle about bad pragmas not just syntax aesthetics),
then you can still use the pragma if you want.

****************************************************************

From: Tucker Taft
Sent: Monday, November 1, 2010  11:54 AM

I now understand your concern about Pure. I don't particularly like having to
make an exception for this case, but if we make one, it will need to be clearly
defined.

We already require static values for many aspects, but deferring most to the
freezing point is no hardship, since that is where the rep-clause would have
taken affect.  So we will need some clear distinction for these particular
aspects for which we won't allow deferral.

Perhaps what you are suggesting is that although it is no hardship, it is also
no great advantage, to permit deferral of Boolean aspects that require a static
value. Obviously if you had omitted the "=> True" you wouldn't be deferring the
determination, so perhaps we can use that as a distinction. Namely if the aspect
is Boolean, and it has to be given statically, then in addition, we say that the
static expression is resolved and evaluated at the point of the aspect
specification.

My one bit of discomfort here is for things such as pragma Pack where we might
want to decide it based on something like the 'Size of something else.  E.g:

    type Arr_Of_Elem is array(...) of Elem
      with Pack => Elem'Size <= System.Storage_Unit/2;

This use of 'Size will cause freezing of Elem, so we might like it to be
deferred as long as possible.

So perhaps we should limit it further to aspects that require a static Boolean
value and that apply to packages or generic packages.

****************************************************************

From: Tucker Taft
Sent: Monday, November 1, 2010  12:29 PM

Coming up with some general rule is not really necessary.  We have already
allowed particular aspects to have their own rules.  So aspects Pure and
Preelaborated, and perhaps the other various "categorization" aspects like
Remote_Types, should have this rule that they require a static expression which
is resolved and evaluated at the point of the aspect specification.  This would
allow use of constants declared in "with"ed packages, but nothing local in the
package.

The rule that the resolution would be the same if it were deferred to after the
end of the package would still seem to be useful to avoid confusion.

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  4:38 PM

I disagree in this case, simply not worth the effort and would require a lot of
extra mechanism. Why not just decide that the whole business of delayed
resolution and checking it is plain silly for these static boolean predicates,
the only arguments that make sense are

True (9x% of the cases)

Some boolean static exptression depending on previously declared stuff (very
small % of remaining cases).

I really think that worrying about having

      type x is array (0 .. 31) of Boolean with
        Pack => True;

      ...

      True : Boolean := False;

being required to generate a message is not worth any discussion, let alone
implementation effort.

It's so much cleaner to say that these aspects are analyzed and evaluated at the
time of the aspect appearing. If it evaluates to True, the aspect is active, if
it is False, then the aspect is entirely ignored, end of story.

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  4:41 PM

> Perhaps what you are suggesting
> is that although it is no hardship, it is also no great advantage, to
> permit deferral of Boolean aspects that require a static value.
> Obviously if you had omitted the "=>  True"
> you wouldn't be deferring the determination, so perhaps we can use
> that as a distinction.
> Namely if the aspect is Boolean, and
> it has to be given statically, then in addition, we say that the
> static expression is resolved and evaluated at the point of the aspect
> specification.

Right, seems reasonable

> My one bit of discomfort here is for things such as pragma Pack where
> we might want to decide it based on something like the 'Size of
> something else.  E.g:
>
>      type Arr_Of_Elem is array(...) of Elem
>        with Pack =>  Elem'Size<= System.Storage_Unit/2;
>
> This use of 'Size will cause freezing of Elem, so we might like it to
> be deferred as long as possible.

Perhaps so, at this stage I have all the (quite complex) mechanism in place for
doing this, so I am cool either way. I actually find the above example fairly
convincing :-)

> So perhaps we should limit it further to aspects that require a static
> Boolean value and that apply to packages or generic packages.

That seems reasonable to me (in fact it is exactly what I have implemented for
now :-))

Have we definely agreed to avoid the cancellation mechanism for derived types
(that will allow me to remove quite a bit of rather messy implementation junk).

****************************************************************

From: Tucker Taft
Sent: Monday, November 1, 2010  4:50 PM

> Have we definely agreed to avoid the cancellation mechanism for
> derived types (that will allow me to remove quite a bit of rather
> messy implementation junk).

I believe we disallowed turning off certain things on derived types.  In
particular, the various aspects relating to shared variables cannot be turned
off (e.g. Atomic, Atomic_Components, ...). I forget whether we extended that to
cover any other aspects, such as Pack.

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  4:53 PM

My recommendation is simply to say that if an aspect is set to False, then it
has no effect, i.e. it is as though it were not present at all, and the fact
that this means that we are NOT trying to cancel any derived type stuff falls
out from this.

I don't like going through things one aspect at a time to figure out what the
effect is. After all we never had this capability before, and I can't remember
anyone ever complaining :-)

****************************************************************

From: Tucker Taft
Sent: Monday, November 1, 2010  5:47 PM

> My recommendation is simply to say that if an aspect is set to False,
> then it has no effect, i.e. it is as though it were not present at
> all, and the fact that this means that we are NOT trying to cancel any
> derived type stuff falls out from this.

That sounds a bit confusing to me.  Why would a boolean-valued aspect have this
non-overriding behavior for just one of its values, while a non-boolean-valued
aspect would have overriding behavior for all of its possible values?

> I don't like going through things one aspect at a time to figure out
> what the effect is. After all we never had this capability before, and
> I can't remember anyone ever complaining :-)

I think you will need a better argument than this to convince the rest of the
ARG. ;-)

****************************************************************

From: Robert Dewar
Sent: Monday, November 1, 2010  6:10 AM

Now I am confused, initially I was in favor of cancellation semantics in all
cases for derived types, and that is what I have implemented.

Now you seem to say the ARG does not want that, I don't really care that much,
but it would be nice if people could make up their minds.

And I do think it would be best to avoid a lot of special case rules
implementing a feature that has never been used.

The reason I think the boolean valued stuff is different is that this is NOT
providing a value to be used, quite different from size or invariant. It is
simply indicating whether the aspect is active or not.

Perhaps the whole business of allowing => True at all is wrong, just insist on
no parameter at all for these cases, after the whole business of cancellation
came up as a surprise when I first raised it :-)

****************************************************************

From: John Barnes
Sent: Tuesday, November 2, 2010  4:40 AM

...
> For me
>
>   package Ada with Pure => True is
>   end Ada;

That's awful. It has that gruesome juxtaposition "is end".

...
> Note the pragma is still there, so if this is just asthetics on your
> part (note for me there is a real principle about bad pragmas not just
> syntax aesthetics), then you can still use the pragma if you want.

I am aware that I can still use the pragmas and I would for Pure etc but what I
really want to know is are you thinking of going all the way through the RM
changing existing text to get rid of the use of pragmas such as Pure?

Don't get me wrong, I think that the introduction of these aspect things is a
wonderful idea. Pre and postconditions would be hopeless without. But I don't
think they are appropriate for Pure etc.

You also have to remember that people read each other's programs and it is
confusing if different people use gratuitously different styles.

****************************************************************

From: Brad Moore
Sent: Tuesday, November 2, 2010  10:00 AM

> That's awful. It has that gruesome juxtaposition "is end".

What if package aspect specifications occurred immediately after the "is"
instead of before, and they allowed an extra aspect mark to appear to the left
of the with, and the with is optional and only needed if more than one aspect
was named.

The idea is that programmers would have the flexibility to choose a style that
best fits the combination of pragmas they wanted to use.

Then I could (and would) write;

package Ada is Pure
end Ada;

This reads very nicely I think.

For a different pragma such as Remote_Types, I would use the other format.

package Ada is with Remote_Types
end Ada;

If I wanted to specify both, I would write

package Ada is Pure
   with Remote_Types

end Ada;

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 2, 2010  10:27 AM

>>> For me
>>>
>>>    package Ada with Pure =>  True is
>>>    end Ada;
>>>
>> That's awful. It has that gruesome juxtaposition "is end".

This makes ZERO sense to me, the aspect stuff does not change that.
That "gruesome juxtaposition" has been in Ada since the very beginning, you have
always been able to say

       package Ada is
       end Ada;

that's normal standard syntax, so John's adverse reactions to it are interesting
but totally irrelevant to this discussion!

> What if package aspect specifications occurred immediately after the
> "is" instead of before, and they allowed an extra aspect mark to
> appear to the left of the with, and the with is optional and only
> needed if more than one aspect was named.
>
> The idea is that programmers would have the flexibility to choose a
> style that best fits the combination of pragmas they wanted to use.
>
> Then I could (and would) write;
>
> package Ada is Pure
> end Ada;

Messy to allow this, given that

   package Ada is Pure : Integer;
   end Ada;

is quite fine.

I really think we should keep the WITH for all aspect specifications, there is
no point in creating special syntax for this one case!

> This reads very nicely I think.

I really do not like the Pure just sitting in the declarative part, it seems odd
to me, and even odder is

   package Ada is Pure
   Pure : Integer;
   end Ada;

Here we have two identifiers occurring together with no punctuation between
them, to see how odd it can become look at

   package Ada is
   Pure XYZ, ABC : Integer;
   end Ada

Now it is just the lack of a comma between Pure and XYZ that makes Pure an
aspect rather than an Integer variable.

You can't seriously think this is a good idea when you see this example :-)

> For a different pragma such as Remote_Types, I would use the other
> format.
>
> package Ada is with Remote_Types
> end Ada;
>
> If I wanted to specify both, I would write
>
> package Ada is Pure
>     with Remote_Types
>
> end Ada;

Getting even worse in my view, this mixing of two syntaxes is really unpleasant.

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 2, 2010  11:44 AM

To me this syntax looks fine:

>      1. pragma Ada_2012;
>      2. package aspectpu with Pure is
>      3.   X : Integer;
>           |
>         >>> declaration of variable not allowed in pure unit
>
>      4. end;

****************************************************************

From: John Barnes
Sent: Wednesday, November 3, 2010  3:19 AM

> This makes ZERO sense to me, the aspect stuff does not change that.
> That "gruesome juxtaposition" has been in Ada since the very
> beginning, you have always been able to say
>
>       package Ada is
>       end Ada;
>
> that's normal standard syntax, so John's adverse reactions to it are
> interesting but totally irrelevant to this discussion!

I have always hated that and would like the option of saying just

package Ada;

just as we can say

task T;

But as you say that is another matter. But it is not irrelevant in the sense
that I am against further uglification

I would advise against too much choice. Just stick to the with and omit => True.
And the elderly can use pragma Pure.

But what I really want to know is are we intending to change all the existing
uses of pragmas such as Pure to the new syntax?

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 3, 2010  4:16 AM

> But what I really want to know is are we intending to change all the
> existing uses of pragmas such as Pure to the new syntax?

That's a coding style question, not a language question. Of course the language
will retain the pragmas (indeed in GNAT, we have introduced new pragmas such as
Invariant and Predicate to take adavtange of these new features in other than
Ada 2012 mode). No one is suggesting the obviously unacceptable step of removing
the pragmas, and if we did it would be a waste of time, since implementations
would leave them in anyway.

Note also that the pragmas are a bit more flexible, e.g. Size can appear in the
private part, which has methodological and functional implications.

****************************************************************

From: Bob Duff
Sent: Wednesday, November 3, 2010  8:51 PM

> But what I really want to know is are we intending to change all the
> existing uses of pragmas such as Pure to the new syntax?

You mean existing pragmas Pure in the various language-defined packages in the
RM?  I've never heard anybody suggest changing those, and I am opposed to
changing those (lots of work, no benefit).

****************************************************************

From: John Barnes
Sent: Thursday, November 4, 2010  3:04 AM

> You mean existing pragmas Pure in the various language-defined
> packages in the RM?  I've never heard anybody suggest changing those,
> and I am opposed to changing those (lots of work, no benefit).

Good. So all this discussion about with Pure is almost academic.  I will ignore
it. John

****************************************************************

From: Bob Duff
Sent: Thursday, November 4, 2010  7:37 AM

> Don't get me wrong, I think that the introduction of these aspect
> things is a wonderful idea. Pre and postconditions would be hopeless
> without. But I don't think they are appropriate for Pure etc.
>
> You also have to remember that people read each other's programs and
> it is confusing if different people use gratuitously different styles.

John, I am also somewhat uncomfortable with the push to make everything under
the sun into an "aspect".  I agree with your "gratuitously different styles"
comment.  And I think it's a lot of work.  (Work that I have apparently been
"volunteered" to do...)

My list of pragmas was not intended as an endorsement -- I was told to come up
with a list of pragmas that might make sense as aspects. The ARG has not yet
discussed this list, so there is no official decision that Pure is an aspect.
My impression is that everybody on ARG thinks it should be, except you don't
like it, and I am ambivalent.  To be discussed.

Robert wants to rush off and implement it all before the language is designed.
He understands that the ARG is still deciding at its usual slow pace.  He also
understands that implementation-defined aspects are allowed, so Pure can be an
aspect without any blessing from ARG, and without using the "-gnatX" (extensions
allowed) switch.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 4, 2010  8:06 AM

> Good. So all this discussion about with Pure is almost academic.  I
> will ignore it. John

By no means academic, since I think it will become preferred usage for many Ada
programmers.

Certainly I will switch the GNAT run-time over to this style in time, since I
prefer important semantic effects like this to be achieved with regular syntax
rather than pragmas.

Also aesthetically, I prefer

    package Types with Pure is
       type Int is new Integer;
       ...
    end Types;

to

    package Types is
       pragma Pure;
       type Int is new Integer;
       ...
    end Types;

since, never mind the pragma issue, the latter form makes the pragma look like
one of the declarations inside the package, rather than setting an attribute of
the package itself.

BTW, this form is now fully implemented in GNAT

****************************************************************

From: Bob Duff
Sent: Thursday, November 4, 2010  8:25 AM

> Certainly I will switch the GNAT run-time over to this style in time,
> since I prefer important semantic effects like this to be achieved
> with regular syntax rather than pragmas.

Pragmas that place restrictions on what you can do (via compile-time or run-time
checked -- doesn't matter) are OK by me.  Pure is mostly (not entirely) in that
category.

Pragma Restrictions is the most obvious one.  You could imagine "pragma
Restrictions (No_Impure_Stuff);" which would mean roughly the same as "pragma
Pure".

****************************************************************

From: Robert Dewar
Sent: Thursday, November 4, 2010  8:32 AM

Right, I would prefer that all such pragmas (ones that serve simply to place
restrictions on what can be done), be spelled Restriction or Profile, and that
other pragmas that are in effect restrictions be avoided.

And as you say, Pure goes a bit beyond this :-)

I also prefer the clarity of the aspect pure being syntactically connected to
the package, rather than appearing like the pragma to be merely one of the
components of the package syntactically.

****************************************************************

From: John Barnes
Sent: Sunday, November 7, 2010  8:07 AM

> Perhaps the whole business of allowing => True at all is wrong, just
> insist on no parameter at all for these cases, after the whole
> business of cancellation came up as a surprise when I first raised it
> :-)

Yes, that seems to be the nub of the issue. Cut out the => True.

****************************************************************

From: Brad Moore
Sent: Thursday, November 11, 2010  10:00 AM

> I also prefer the clarity of the aspect pure being syntactically
> connected to the package, rather than appearing like the pragma to be
> merely one of the components of the package syntactically.

I have the following library level generic instantiation.

     with Buffers.Simple_Unbounded;

     package String_Buffers.Simple_Unbounded_Buffer
         is new String_Buffers.Simple_Unbounded;

     pragma Preelaborate (String_Buffers.Simple_Unbounded_Buffer);
     pragma Remote_Types (String_Buffers.Simple_Unbounded_Buffer);

Presumably, I'd now be able to write instead;

     with Buffers.Simple_Unbounded;

     package String_Buffers.Simple_Unbounded_Buffer with Remote_Types, Preelaborate
        is new String_Buffers.Simple_Unbounded;

without having to respecify the package name on each of the aspects.
That is quite a bit cleaner than the pragma version.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 11, 2010  10:18 AM

> without having to respecify the package name on each of the aspects.
> That is quite a bit cleaner than the pragma version.

I don't understand this, if this is indeed intended, it is a surprise to me. To
me the aspect was just a syntactic equivalent for the pragma in a case like
this.

****************************************************************

From: Tucker Taft
Sent: Thursday, November 11, 2010  11:03 AM

> Presumably, I'd now be able to write instead;
>
> with Buffers.Simple_Unbounded;
>
> package String_Buffers.Simple_Unbounded_Buffer with Remote_Types,
> Preelaborate is new String_Buffers.Simple_Unbounded;

The syntax in 12.3 indicates that the aspect specification comes just before the
";" in an instantiation.  Hence:

    package String_Buffers.Simple_Unbounded_Buffer is
      new String_Buffers.Simple_Unbounded
      with Remote_Types, Preelaborate;

>> without having to respecify the package name on each of the aspects.
>> That is quite a bit cleaner than the pragma version.
>
> I don't understand this, if this is indeed intended, it is a surprise
> to me. To me the aspect was just a syntactic equivalent for the pragma
> in a case like this.

I don't understand what you don't understand ;-).  Brad is pointing out an
example of how the aspect specification can be cleaner (syntactically, I presume
he means) than a categorization or elaboration-control pragma.  Other than the
positioning of the aspect clause, his example seems valid.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 11, 2010  12:44 PM

> I don't understand what you don't understand ;-).  Brad is pointing
> out an example of how the aspect specification can be cleaner
> (syntactically, I presume he means) than a categorization or
> elaboration-control pragma.  Other than the positioning of the aspect
> clause, his example seems valid.

Ah because of the mispositioning, I missed them entirely glancing at his
example, and thought he was somehow suggesting that they got inherited from the
aspects of the template :-)

> It is interesting to imagine extending the syntax to allow aspect
> specifications on "with" clauses:
>
>      with Ada.Text_IO
>        with Elaborate_All;
>
> Someone else might have already mentioned the issue with this
> extension creating an error prone situation where leaving off a ";"
> will produce a significantly different interpretation!
>
> Probably not worth going there...

Don't like this idea at all. Bad enough to have WITH meaning two such very
different things, and to put these conflicting uses into close alliance is a
mistake (the phenomenon of the missing semicolon just reemphasizes the basic
mistake

The worse case is

       with Ada.Text_IO
       with My_Package;

where now presumably you get a diagnostic saying My_Package is not a valid
aspect name, instead of missing semicolon (and of course it's even worse if the
name of the second package *does* happen to match an aspect name, as in

       with Ada.Text_IO
       with Size;
                |
                missing =>

or

       with Ada.Text_IO
       with Inline;
            |
            Inline aspect cannot be applied to package

****************************************************************

From: John Barnes
Sent: Thursday, November 11, 2010  5:42 PM

from brief glimpses of this thread from a tropical rainforest in Queensland
there seems to me to be a risk of

with A_Mess;

****************************************************************

From: Robert Dewar
Sent: Thursday, November 11, 2010  7:07 PM

Sorry I don't get your reaction at all, my query was answered completely, and I
don't see any problem at all?

****************************************************************

From: John Barnes
Sent: Friday, November 12, 2010  5:21 AM

Well, I did say I only had brief glimpses but it did seem that there was the
risk of confusion with multiple use of with.

And I continue to be cautious of providing multiple ways of doing one thing with
concern for those who have to maintain software.  If the standard libraries
continue to have pragmas for pure, remote types etc, it could be a muddle for
new user code to do those things a different way.

Maybe we should move all the pragmas to J and rewrite the existing standard
packages??

And it could add even more wretched pages to a certain book!!

****************************************************************

From: Robert Dewar
Sent: Friday, November 12, 2010  8:11 AM

> Maybe we should move all the pragmas to J and rewrite the existing
> standard packages??

I find this a waste of time. In fact the pragmas have uses not satisfied by the
aspects and vice versa, I think it is fine to have both forms.

And moving things to Annex J is always a waste of time, these things are not
going away, and it would be unhelpful for pragma Restrictions
(No_Obsolescent_Features) to ban all these pragmas, which are pervasive in the
existing Ada code base.

****************************************************************

From: Robert Dewar
Sent: Friday, November 12, 2010  8:12 AM

> Well, I did say I only had brief glimpses but it did seem that there
> was the risk of confusion with multiple use of with.

Please don't condition your response on a suggestion that there is no real
enthusiasm for and which even the suggester disavows (allowing aspect on WITH
clause).

****************************************************************

From: Bob Duff
Sent: Sunday, January 23, 2011  6:19 PM

The Fairfax minutes say:

    Bob will figure out the wording needed to allow Priority and CPU as
    aspects.

which I'm not sure how to approach.  Rewrite the pragma Priority section to
allow "task ... with Priority => ..."?  And say something in general about how
aspects can be misc pragmas not mentioned already in this AI?

Maybe the CPU thing should be ONLY an aspect (since everybody seems to prefer
aspects nowadays)?

I don't see anything about this in the Nov phone meeting minutes.

Anyway, I think somebody in the "Everything's an Aspect" school of thought ought
to take over the main authorship of this AI. The above "with a few topics" is
really referring to pretty-much everything.

****************************************************************

From: Randy Brukardt
Sent: Monday, January 24, 2011  10:14 PM

> Maybe the CPU thing should be ONLY an aspect (since everybody seems to
> prefer aspects nowadays)?

I don't think that there is anything general that needs to be said about
pragmas. Remember that there is supposed to be an entire annex listing
specifiable aspects. (That's the job I need to do, which is to discuss with you
the best form of that annex. I'll do that off-line here.)

As far as CPU goes, I thought we had decided to dump the pragma. But I obviously
didn't record that, so we'll probably have to talk about it again.

...
> Anyway, I think somebody in the "Everything's an Aspect"
> school of thought ought to take over the main authorship of this AI.
> The above "with a few topics" is really referring to pretty-much
> everything.

No, someone still has to write the text for the introduction to the aspect annex
and to suggest a common form for the entries in that annex. My job is just to
verify that it can be automated (we want it to work like the attribute annex in
terms of the actual source code). So that is more than just the stuff assigned
to Tucker.

The real problem is that I don't think we have anyone else that we can count on
to get the work done in a timely fashion. If you can find someone else to take
it over, I won't mind presuming that person isn't named Tucker. :-)

****************************************************************

From: Bob Duff
Sent: Tuesday, January 25, 2011  9:55 AM

> I don't think that there is anything general that needs to be said
> about pragmas.

I already wrote something general for representation pragmas.
People complained that it doesn't cover Inline and CPU.  (Others?)

>...Remember that there is supposed to be an entire annex listing
>specifiable aspects. (That's the job I need to do, which is to discuss
>with  you the best form of that annex. I'll do that off-line here.)
>
> As far as CPU goes, I thought we had decided to dump the pragma. But I
> obviously didn't record that, so we'll probably have to talk about it again.

If you mean CPU should be an aspect instead of a pragma, then I think that's a
good idea, and I do (vaguely) remember discussing that.  I think there are two
AI's that mention this pragma -- the one that defines it, and the one about
dispatching domains that I took over from Alan.

> ...
> > Anyway, I think somebody in the "Everything's an Aspect"
> > school of thought ought to take over the main authorship of this AI.
> > The above "with a few topics" is really referring to pretty-much
> > everything.
>
> No, someone still has to write the text for the introduction to the
> aspect annex and to suggest a common form for the entries in that
> annex. My job is just to verify that it can be automated (we want it
> to work like the attribute annex in terms of the actual source code).
> So that is more than just the stuff assigned to Tucker.

As I said privately, I'm not convinced such an Annex is necessary.

I already sent you an "introduction" privately.  No big deal.

As to the entries, I wouldn't do them like attributes (where the entire text is
duplicated in the annex).  I'd just put a command like:

    @aspect{CPU, "The CPU on which to execute a task."}

immediately before/after the place where CPU is defined.
This would generate no text inline, and generate alphabetized text in the Annex.

> The real problem is that I don't think we have anyone else that we can
> count on to get the work done in a timely fashion. If you can find
> someone else to take it over, I won't mind presuming that person isn't
> named Tucker. :-)

Shrug.  It seems simple enough to produce this annex.
I'm happy to write the words (if everybody (except me!) agrees that the RM
should weigh 50 pounds).

****************************************************************

From: Bob Duff
Sent: Tuesday, February  8, 2011  2:21 PM

Regarding AI05-0229-1, the minutes of the Jan 27, 2011 phone meeting say:

> Summary of action items:
> Bob:
...
>      AI05-0229-1 - Work out the form and contents of the aspect annex clause
>		     with Randy.
...

For "form", see below.

For "content", I don't see the hurry.  I think I should wait until we have a
more settled list of them, with relevant semantics.  I don't even know what they
all are, at this point.

As I said, I think it's easy: I plan to write an informal one-liner for each
aspect to go in this (useless!) annex.

> AI05-0229-1/01 Specifiable aspects

> Tucker suggests that we could put them as two separate sections in
> Annex K. That seems like a good idea as they are related. The title
> will be challenge, but we can leave that to Bob. [I'm expecting a
> title like "Useless listing of language-defined attributes and
> aspects". :-) - Editor.]

[The text here is part of version /02 of this AI. - Editor]

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  12:27 AM

...
> For "content", I don't see the hurry.  I think I should wait until we
> have a more settled list of them, with relevant semantics.  I don't
> even know what they all are, at this point.

I had wanted some examples for Draft 11. But since I didn't add this annex in
that draft, you'll have until mid-March to provide the content.

Keep in mind that we're supposed to finish all work on the standard at this
upcoming meeting, and the next AARM draft will be going out for editorial and
National Body review. The annex will need to be in that version.

I don't plan to put the actual entries into the AI, just the standard.

...
> Precondition: Specifies a condition that must hold true in order to
> call a given subprogram.

The existing annexes include an (automated) cross-reference to the section of
definition. We'll certainly do that here, too; that's kinda the point. So this
will end with "See 13.3.1.". You'll need to keep that in mind as you write
these.

> Size: See attribute below.

That wouldn't make any sense, with the automatic cross-reference.

Size: See attribute below. See 13.3.

!!!

>     Or maybe:
>
> Size: Size in bits of a subtype or object (see Size attribute below).

Same here:

Size: Size in bits of a subtype or object (see Size attribute below). See 13.3.

The following would work, of course.

Size: Size in bits of a subtype or object. See 13.3.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011  2:43 AM

...
> And I finished the rest of my ARG homework, too, I think.

Back on January 24th, you wrote:

I have completed all of the above homework (yay!), except for AI05-0229-1.
The Fairfax minutes say:

    Bob will figure out the wording needed to allow Priority and CPU as
    aspects.

which I'm not sure how to approach.  Rewrite the pragma Priority section to
allow "task ... with Priority => ..."?  And say something in general about how
aspects can be misc pragmas not mentioned already in this AI?

Maybe the CPU thing should be ONLY an aspect (since everybody seems to prefer
aspects nowadays

====

You never did this. I'm happy to tell you how to approach it - just write the
wording needed to augment/replace that for each pragma. I don't think there is
any way to generalize it, and I don't see much point anyway.

You'll also have to help me figure out what parts of your mail from last October
belongs in this AI; I never considered it as approproate AI contents but since I
don't seem to be getting anything else I guess I'll have to try to figure out
how to turn it into something that makes sense as wording and AARM notes...

****************************************************************

From: Bob Duff
Sent: Friday, February 11, 2011  9:05 AM

> Maybe the CPU thing should be ONLY an aspect (since everybody seems to
> prefer aspects nowadays

Nobody answered this question.  Should I submit a new version of AI05-0171-1,
"Pragma CPU and Ravenscar Profile" with a different subject, and change the
pragma into an aspect?  That AI is currently ARG Approved.

AI05-0167-1, "Managing affinities for programs executing on multiprocessors"
refers to pragma CPU, so should I submit a new version of that AI, too?

And if CPU is an aspect instead of a pragma, then should I change
Dispatching_Domain (in AI05-0167-1) to also be an aspect?

Are the latest versions of these AIs in the CVS repository?

...
> You'll also have to help me figure out what parts of your mail from
> last October belongs in this AI; I never considered it as approproate
> AI contents but since I don't seem to be getting anything else I guess
> I'll have to try to figure out how to turn it into something that
> makes sense as wording and AARM notes...

Yes, please.  I'm not the one pushing for everything under the sun to be turned
into an aspect.  I don't think it's feasible, so those who do should put up some
wording.  I did my best, but don't be surprised that what I did is incomplete.

****************************************************************

From: Randy Brukardt
Sent: Friday, February 11, 2011  12:57 PM

> Nobody answered this question.  Should I submit a new version of
> AI05-0171-1, "Pragma CPU and Ravenscar Profile" with a different
> subject, and change the pragma into an aspect?
> That AI is currently ARG Approved.

That's fine, or you can just put new wording into AI05-0229-1. AIs can still be
changed until they are WG 9 approved, so it is probably better that we go that
way.

> AI05-0167-1, "Managing affinities for programs executing on
> multiprocessors" refers to pragma CPU, so should I submit a new
> version of that AI, too?

Sure.

> And if CPU is an aspect instead of a pragma, then should I change
> Dispatching_Domain (in AI05-0167-1) to also be an aspect?

I think so.

> Are the latest versions of these AIs in the CVS repository?

Yes, with the possible exception of the AI-167 you sent the other day. I've
filed it here, but I don't know if I've uploaded the changes since I did that.

...
> > You'll also have to help me figure out what parts of your mail from
> > last October belongs in this AI; I never considered it as
> > approproate AI contents but since I don't seem to be getting
> > anything else I guess I'll have to try to figure out how to turn it
> > into something that makes sense as wording and AARM notes...
>
> Yes, please.  I'm not the one pushing for everything under the sun to
> be turned into an aspect.  I don't think it's feasible, so those who
> do should put up some wording.  I did my best, but don't be surprised
> that what I did is incomplete.

OK. We can do that off-line (no need to clutter this list with discussions of AI
formats).

****************************************************************

From: Alan Burns
Sent: Saturday, February 12, 2011  6:01 AM

I've not been following the discussions about aspects, so I'm not sure what the
consequences are for changing from a pragma to an aspect - but for us real-time
folk a consistent language style is what we most need. We already have pragmas
for priority, profiles and initial deadline, so can we not also have pragmas for
affinities?

Or are all these other pragmas also changing?

In telling people about the support that Ada provides for multicores I would
prefer not to have to also talk about changes to the things they already know
(unless the change to aspect in just a pure syntax change).

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  8:22 PM

> I've not been following the discussions about aspects, so I'm not sure
> what the consequences are for changing from a pragma to an aspect -
> but for us real-time folk a consistent language style is what we most
> need.
> We already have pragmas for priority, profiles and initial deadline,
> so can we not also have pragmas for affinities?
>
> Or are all these other pragmas also changing?

Virtually all pragmas will be also available in aspect form. In new code,
aspects will be preferred (at least IMHO).

> In telling people about the support that Ada provides for multicores I
> would prefer not to have to also talk about changes to the things they
> already know (unless the change to aspect in just a pure syntax
> change).

There is no semantic difference between specifying properties with attributes,
pragmas, or aspects. So it is just a syntax change.

****************************************************************

From: Alan Burns
Sent: Monday, February 14, 2011  7:54 AM

> Virtually all pragmas will be also available in aspect form. In new
> code, aspects will be preferred (at least IMHO).

Can I put in a plea for both forms being available with multiprocessor pragmas
(ie not just aspects)

****************************************************************

From: Bob Duff
Sent: Saturday, February 12, 2011  7:29 AM

> ...
> > For "content", I don't see the hurry.  I think I should wait until
> > we have a more settled list of them, with relevant semantics.  I
> > don't even know what they all are, at this point.
>
> I had wanted some examples for Draft 11. But since I didn't add this
> annex in that draft, you'll have until mid-March to provide the content.

Well, I've given several off-the-cuff examples in the past.

How about you give me a macro format, and a list of aspects, and I'll write them
all up?  If your list is incomplete, I'll complete it later.  I'll give you
something like:

    After 1.2.3(45):
    @aspect-index-entry{Precondition|Specifies a condition that must
    hold true in order to call a given subprogram.}

(or whatever the correct macro-call syntax is -- I assume it's still vaguely based
on Scribe).  The macro will automatically generate an entry in the Annex, including
the section number, plus an entry in the index.

Tell me whether you want the macro call before, after, or part of the relevant
paragraph.

> Keep in mind that we're supposed to finish all work on the standard at
> this upcoming meeting, and the next AARM draft will be going out for
> editorial and National Body review. The annex will need to be in that version.
>
> I don't plan to put the actual entries into the AI, just the standard.
>
> ...
> > Precondition: Specifies a condition that must hold true in order to
> > call a given subprogram.
>
> The existing annexes include an (automated) cross-reference to the
> section of definition. We'll certainly do that here, too; that's kinda
> the point. So this will end with "See 13.3.1.". You'll need to keep
> that in mind as you write these.
>
> > Size: See attribute below.
>
> That wouldn't make any sense, with the automatic cross-reference.
>
> Size: See attribute below. See 13.3.
>
> !!!

OK, then:

Size (also attribute). See 13.3.

And the intro would say "Some aspects are also attributes, as noted, see
Whatever.

> >     Or maybe:
> >
> > Size: Size in bits of a subtype or object (see Size attribute below).
>
> Same here:
>
> Size: Size in bits of a subtype or object (see Size attribute below).
> See 13.3.

If you insist on defining every attribute THREE times, then:

Size: Size in bits of a subtype or object (same as Size attribute).
See 13.3.

> The following would work, of course.
>
> Size: Size in bits of a subtype or object. See 13.3.

Don't you think it's useful to say which aspects are also attributes or pragmas?
(Preferably instead of describing them, but in addition, if you insist.)

In that case, how about 3 macros, one for aspects that are also pragams, one for
also-attrs, and one for the rest? They can generate appropriate canned text,
such as " (also an attribute)".

Actually, forget the pragma one -- we want people to switch entirely over to the
aspect.  But attributes are still useful as queries.

Here's another idea (sorry for the stream-of-conciousness e-mail!):

Size: X'Size is the size in bits of subtype or object X.
See 13.3.

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  8:10 AM

> How about you give me a macro format, and a list of aspects, and I'll
> write them all up?  If your list is incomplete, I'll complete it
> later.  I'll give you something like:
>
>     After 1.2.3(45):
>     @aspect-index-entry{Precondition|Specifies a condition that must
>     hold true in order to call a given subprogram.}
>
> (or whatever the correct macro-call syntax is -- I assume it's still
> vaguely based on Scribe).  The macro will automatically generate an
> entry in the Annex, including the section number, plus an entry in the
> index.

That's fine, although just pairs (aspect, description) would be enough.

Looking at the existing commands, I think we'll have something like

@chgaspectdesc{Version=[<version>],Kind=[<kind>],Aspect=[<text>],Text=[<text
>]}

(So we have everything we'll need going forward.) For this version, that will
look like:

@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Precondition],
Text=[Specifies a condition that must hold true in order to call a given subprogram.]}

The first two items will be the same for all of these.

> Tell me whether you want the macro call before, after, or part of the
> relevant paragraph.

I think after (like @ImplDef and @ChgImplDef).

...
> If you insist on defining every attribute THREE times, then:
>
> Size: Size in bits of a subtype or object (same as Size attribute).
> See 13.3.

This isn't a definition, it's a reference list.

> > The following would work, of course.
> >
> > Size: Size in bits of a subtype or object. See 13.3.
>
> Don't you think it's useful to say which aspects are also attributes
> or pragmas?  (Preferably instead of describing them, but in addition,
> if you insist.)

I don't see the point off-hand, but I could be convinced.

The typical use for this annex is when you are looking for an aspect that you
want to specify whose name you don't remember. Whether or not it can be queried
with an attribute isn't terribly relevant to that. If you know the name, you'd
probably use the main index or the search page. It's only when you don't know
the name that these lists come in handy.

One can imagine that the list of aspects is of things that you can specify; the
list of attributes is of things you can query. These seem like disjoint lists to
me.

> In that case, how about 3 macros, one for aspects that are also
> pragams, one for also-attrs, and one for the rest?
> They can generate appropriate canned text, such as " (also an
> attribute)".

Sounds like overkill to me.

> Actually, forget the pragma one -- we want people to switch entirely
> over to the aspect.  But attributes are still useful as queries.
>
> Here's another idea (sorry for the stream-of-conciousness e-mail!):
>
> Size: X'Size is the size in bits of subtype or object X.
> See 13.3.

I suppose that would work. Still doesn't seem necessary to me. Does anyone else
have an opinion about whether these entries should include information about the
associated pragma or attribute?

****************************************************************

From: John Barnes
Sent: Wednesday, February 16, 2011  4:07 AM

I am sorry not to be with you again at the meeting in sunny Florida.
Although improving, I am still very reluctant to fly. I am especially annoyed at
missing the opportunity to see the new Dali museum.

In my absence, Jeff Cousins is taking my place. I am sure I will see you all in
Edinburgh.  Meanwhile, please read the following:

As you will have perceived from reading the latest draft of the Rationale
I am unhappy with two areas of Ada 2012. One is some aspects of
aspects (groan); the other is subtype predicates..

[For the predicate part of the discussion, see AI05-0153-3.]

Aspects.

Although the use of the new aspect syntax is excellent for attaching
properties to subprograms, there are misgivings with other uses and
especially when replacing pragmas relating to packages, task and protected
objects by aspects.

One problem is the overuse of with. The definition of the protected type
Queue in Unbounded_Synchronized_Queues is now

   protected type Queue(Ceiling: Any_Priority := Default_Ceiling)
                               with Priority => Ceiling
                                    is new Queue_Interfaces.Queue with
    .... etc

In close proximity we have two quite different uses of "with". Moreover, a
few lines above we have "with System" and "with package Queue_Interfaces".
So altogether four different uses of "with". Clearly we cannot do anything
about three of them.

This could be solved by introducing another reserved word for aspects. But
somehow I doubt whether we will find one we like. Alternatively this can be
solved by reverting to the use of pragmas in this situation thus

protected type Queue(Ceiling: Any_Priority := Default_Ceiling)
                                      is new Queue_Interfaces.Queue with
     pragma Priority(Ceiling);

    .... etc

I further understand from Alan that the Real-Time community and especially
the IRTAW group are perfectly happy with the use of pragmas for features
such as Priority and would not want to change. Moreover, for new features
such as CPU they want to use a pragma for consistency with the things such
as Priority. There is no objection to the introduction of an aspect for CPU
as well but the pragma is definitely required.

We should heed and take action on their request.

****************************************************************

From: Robert Dewar
Sent: Wednesday, February 16, 2011  7:11 AM

> Although the use of the new aspect syntax is excellent for attaching
>
> properties to subprograms, there are misgivings with other uses and
>
> especially when replacing pragmas relating to packages, task and
> protected
>
> objects by aspects.

Hmmm, these are uses which seem very natural and convenient to me, I much prefer

    package X with Pure is ..

to

    package X is
      pragma Pure;

oh well ... tastes differ, the pragmas are still there of course.
I suppose we could remove them, the same way we removed all the Ada 83 pragmas,
knowing that implementations would put them back anyway :-)

It would leave the language definition cleaner to do this without compromising
portability in practice, and as I say, we do have a precedent for this action.

> I further understand from Alan that the Real-Time community and
> especially the IRTAW group are perfectly happy with the use of pragmas for
> features such as Priority and would not want to change.

I doubt anyone can speak for "the Real-Time community", certainly IRTAW does not
have strong contacts with many commercial embedded real time producers. I expect
that in practice some will use the pragmas and some will switch to the aspects.
For myself, I prefer the use of aspects in all cases, and I don't find the extra
use of WITH confusing, it is easy for the parser and easy for at least this
human to distinguish the uses.

> Moreover, for new features
> such as CPU they want to use a pragma for consistency with the things
> such as Priority. There is no objection to the introduction of an aspect
> for CPU as well but the pragma is definitely required.

Well I am not sure I would pay too much attention to the particular tastest of
one particular group, and in any case certainly GNAT will have both anyway, I
would be opposed to adding both to Ada 2012, that's unnecessary redundancy.

> We should heed and take action on their request.

When it comes to aesthetic choices between two equivalent syntaxes, you will
always find people who strongly prefer one and others who strongly prefer the
other. That's not a reason to put both in the language!

****************************************************************

From: Bob Duff
Sent: Wednesday, February 16, 2011  8:51 AM

Randy has to file these emails in the appropriate AI, so we should have one
subject per email.  I'll reply to your "aspect" comments here, and send a
separate email about "predicates".

> I am sorry not to be with you again at the meeting in sunny Florida.

We'll miss you!

> Aspects.
>
> Although the use of the new aspect syntax is excellent for attaching
> properties to subprograms, there are misgivings with other uses and
> especially when replacing pragmas relating to packages, task and
> protected objects by aspects.

I agree with you, regarding type extensions -- the two "with"s are slightly
jarring.  But I don't think it's a big deal, and I haven't seen any better
proposals, and I haven't been able to come up with anything better myself.

I disagree with you about packages, tasks, and protecteds.
There, the with clauses seem sufficiently separated from the aspect clauses.

> I further understand from Alan that the Real-Time community and
> especially the IRTAW group are perfectly happy with the use of pragmas
> for features such as Priority and would not want to change. Moreover,
> for new features such as CPU they want to use a pragma for consistency
> with the things such as Priority. There is no objection to the
> introduction of an aspect for CPU as well but the pragma is definitely required.

I have mixed feelings about that.  Obviously, if Priority is an aspect, we need
to keep the pragma for compatibility reasons.

I was planning to make CPU and Dispatching_Domain into aspects, and drop the
pragmas.  But before I got a chance to write that up, Alan argued against that,
so I decided not to write anything up, but see what folks think at the meeting.

Two things bother me about having both.  It's a pain to write the RM wording.
And I hate to see the language split into two dialects, some folks refusing to
use aspects, and others refusing to use pragmas. It's like "in" on parameters.
Three dialects in that case -- (1) always say "in", (2) never say "in", (3) "in"
on procedures, not on functions.  There is no value in allowing these kinds of
choices.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 16, 2011  11:35 AM

If you are not going to write up something, it would be best if you told your
editor so he did not think you were shirking your work. I spent most of
yesterday doing it. I ended up leaving the pragmas as aspects are not allowed on
subprogram bodies. This has to be done at this meeting and doing this wording at
night is not practical.

(Sending mail from my phone is such fun.)

****************************************************************

From: Bob Duff
Sent: Wednesday, February 16, 2011  11:58 AM

> If you are not going to write up something, it would be best if you
> told your editor so he did not think you were shirking your work.

But I WAS shirking (sorry).  At least I completed all my other homework.

> I spent most of yesterday doing it.

Thanks.

>...I ended up leaving the pragmas as
> aspests are not allowed on subprogram bodies. This has to be done at
>this  meeting and doing this wording at night is not practical.

OK.  I was having trouble seeing how to do that without duplicating a lot of
wording (which is part of my reason for shirking), so I'll look forward to
seeing what you did.

> (Sending mail from my phone is such fun.)

I don't know how to send mail from a phone!

****************************************************************

From: John Barnes
Sent: Friday, February 18, 2011  7:42 AM

> I have mixed feelings about that.  Obviously, if Priority is an
> aspect, we need to keep the pragma for compatibility reasons.
>
> I was planning to make CPU and Dispatching_Domain into aspects, and
> drop the pragmas.  But before I got a chance to write that up, Alan
> argued against that, so I decided not to write anything up, but see
> what folks think at the meeting.
>
> Two things bother me about having both.  It's a pain to write the RM
> wording.  And I hate to see the language split into two dialects, some
> folks refusing to use aspects, and others refusing to use pragmas.
> It's like "in" on parameters.  Three dialects in that case -- (1)
> always say "in", (2) never say "in",
> (3) "in" on procedures, not on functions.  There is no value in
> allowing these kinds of choices.

I don't mind having both aspects and pragmas for CPU and Dispatching_Domain. I
shouldn't have thought it was too much of a bother about the wording because you
can presumably use the same arrangement as has to be used for Priority.

In general I don't like two ways of doing the same thing because it means that
programmers use different styles and that can make it harder for program
maintenance. But we have added several features in the past that have resulted
in two ways to do things. An obvious example is the prefix notation for
subprogram calls. Good marketing no doubt and I don't disagree with it at all.
Another example is introducing anonymous access types. Maybe that was meant to
be for marketing as well; but it gave us lots of accessibility pain and made
writing my book rather confusing.

In a sense this is a marketing issue as well. We don't want to upset the
real-time folks if they are happier with pragmas.

Of course, generally aspects are wonderful. The first attempt to do pre and post
conditions with pragmas was truly gruesome.

So my preference is to give them both.

****************************************************************

From: Robert Dewar
Sent: Friday, February 18, 2011  8:00 AM

>> I have mixed feelings about that.  Obviously, if Priority is an
>> aspect, we need to keep the pragma for compatibility reasons.

As I said in a previous message, this is not obvious at all.
We dropped Ada 83 pragmas knowing that implementors would keep them.

...
> I don't mind having both aspects and pragmas for CPU and Dispatching_Domain.
> I shouldn't have thought it was too much of a bother about the wording
> because you can presumably use the same arrangement as has to be used
> for Priority.
>
> In general I don't like two ways of doing the same thing because it
> means that programmers use different styles and that can make it
> harder for program maintenance. But we have added several features in
> the past that have resulted in two ways to do things. An obvious
> example is the prefix notation for subprogram calls. Good marketing no
> doubt and I don't disagree with it at all. Another example is
> introducing anonymous access types. Maybe that was meant to be for
> marketing as well; but it gave us lots of accessibility pain and made writing my book rather confusing.
>
> In a sense this is a marketing issue as well. We don't want to upset
> the real-time folks if they are happier with pragmas.

Please don't assume that the aesthetic tastes of a few represent the wishes of
the "real=time folks". We do a lot because of personal preferences (Tuck doesn't
like IN OUT function parameters unless we have strange rules about side effects,
Randy doesn't like one aspect for predicates etc). Not terrible, and probably
not so important, since compilers are in the business of accomodating multiple
tastes anyway (GNAT already has three predicates:

Static_Predicate
Dynamic_Predicate
Predicate

the latter impl-defined, is like static predicate if it meets the rules for SP,
and otherwise like dynamic predicate.

> Of course, generally aspects are wonderful. The first attempt to do
> pre and post conditions with pragmas was truly gruesome.

Doesn't seem so gruesome to me, and will always be available in GNAT (big
advantage over aspects, you can use them in Ada 95 and Ada 2005, which is why we
always provide pragmas as well, although I abandoned pragma Predicate as too
hard to implement at the time, but might revisit it).

> So my preference is to give them both.

Well don't spend too much anguish over the decision, for quite a while (for
ever?) all the Ada 2012 compilers in the world will implement both forms
whatever the ARG decides :-)

****************************************************************

From: Brad Moore
Sent: Saturday, February 19, 2011  8:04 AM

An editorial comment:

The AARM note in the wording section says "
   The following representation pragmas cannot be specified using an
   aspect_specification, because the pragma arguments wouldn't make
   sense as an aspect_definition:

      CPU ???
      Convention   B.1(28)
      Export   B.1(28)
      Import   B.1(28)"
yet the AI is about adding the ability to specify aspects for these (except
CPU?). I suspect this section needs updating.

[Editor's note: I think he was reading something old; there is no such text
in the body of the AI as of Feb. 14.]

I hope the meeting in Tampa is going well, and sorry I cannot be there.
I am in Montreal this weekend, my daughter is applying at McGill.

****************************************************************

From: John Barnes
Sent: Thursday, April  7, 2011  5:48 AM

Indeed this is huge and needs a quiet weekend in bed with a mild infection such
as gout.

However, on a quick skim through all seems OK. But I wonder why
Preelaborable_Initialization is not left as a pragma like Pure etc.  It sems to
be the same sort of thing. Could confuse and puzzle users.  Maybe it's just me
and because I describe these things in the same section of my book.

****************************************************************

From: Randy Brukardt
Sent: Thursday, April  7, 2011  11:49 AM

The strategy is that types, objects, and subprograms always use aspects rather
than pragmas, while packages use pragmas. Thus P_I (which works on types) is
described as an aspect. This should be a fairly easy rule to describe to your
readers.

****************************************************************

From: Robert Dewar
Sent: Friday, April  8, 2011  6:13 PM

GNAT will provide pragmas as well as aspects for all these kinds of things, so
that they can be used in other than Ada 2012 mode, and in any case we implement
aspects by translating them to the corresponding pragmas or attribute definition
clauses.

So in terms of actual use, it won't make a difference what the language decices
here.

****************************************************************

From: John Barnes
Sent: Monday, April 11, 2011  5:27 AM

However, the recent phone meeting changed Preelaborable_Initialization to remain
just as a pragma. Nothing to do with my book, but to do with views.

****************************************************************

From: John Barnes
Sent: Tuesday, April 12, 2011  11:05 AM

Am I right in assuming that we prefer to say

"the aspect Whatever" rather than "the Whatever aspect"?

However, AI-229 has a few instances of the second. Particularly "the Pack
aspect".

****************************************************************

From: Ed Schonberg
Sent: Tuesday, April 12, 2011  11:15 AM

I raised that question at the last phone meeting. My preference is for "aspect
Whatever" but I was told that no single form has been adopted, and it was up to
the ear of whoever wrote a particular paragraph.  Personally I prefer the first
form.

****************************************************************

From: Tucker Taft
Sent: Tuesday, April 12, 2011  11:26 AM

I would vote for either "aspect Blah" or "the Blah aspect."
Adding "the" in front of "aspect Blah" doesn't sound right to me.

****************************************************************

From: John Barnes
Sent: Tuesday, April 12, 2011  11:57 AM

Well the AI is riddled with all sorts of aspects. Some with the and some
without. There are lots of "the aspect Blah".

****************************************************************

From: Randy Brukardt
Sent: Tuesday, April 12, 2011  1:24 PM

With AI05-0229-1, I preferred to say whatever made the least change to the
existing wording (didn't want to introduce bugs with this rewording). When
possible, that just meant changing "pragma" to "aspect". And there is no
consistency about how pragmas are identified in text.

Note that at least 4 people worded parts of this AI over about 2 months, and the
wording being changed is in very many different styles, so the styles aren't
that consistent. And in any case it has not been approved or reviewed yet, I
still have to apply the changes from the phone meeting to it. So presume it will
change some more (but not too drastically).

P.S. I'd just as soon this AI got reviewed before I put it into the Standard, so
if you are finding specific things to change, please point them out.

****************************************************************

From: Robert Dewar
Sent: Wednesday, April 13, 2011  8:15 AM

> I would vote for either "aspect Blah" or "the Blah aspect."
> Adding "the" in front of "aspect Blah" doesn't sound right to me.

I agree with Tuck, and I don't see a need to force consistency, the choice of
which of these sounds nicer depends on the circumstance.

****************************************************************

From: Erhard Ploedereder
Sent: Sunday, May 15, 2011  11:31 AM

[The appropriate part of a longer message - Editor.]

AI05-0229-1/09  Specifiable aspects
   [Changes from phone meeting: moved xxx_components aspect to be array type only;
    removed Preelaborable_Initialization (it will remain a pragma); added legality
    rules to prevent various aspects from being specified on interfaces; added
    change of pragma Convention to an aspect in predefined packages.]
   Approve ______ Disapprove __X____ Abstain _______

=====================

>  A representation pragma or library unit pragma that has a single
> argument that  is a local_name may be specified by an
> aspect_specification, with the entity  being the local_name. The aspect_definition is expected to be of type Boolean.
>  The expression shall be static.

surely it is not a pragma that is specified. (and stacking the "that"s 3-deep is
not nice).  Suggested Rewrite:

Any aspect specified by a representation pragma or library unit pragma that has
a local_name as its single argument may be specified by an aspect_specification,
with the entity being the local_name. The aspect_definition is expected to be of
type Boolean.  The expression shall be static.

>    If directly specified, the aspect_definition shall be a static expression.
>     [Redundant: This aspect is never inherited;] ....

Why is this redundant? 13.1 (15/1) says exactly the opposite. It is a
representational aspect after all. Same comment for Inline and possibly others.

>  Replace C.6(10) with the following two paragraphs:
>  If one of these aspects is specified for a component_declaration, the
> declaration  shall not be inherited.

Ambiguous wording. Can be read as an inheritance rule (hiding the
component) rather than an aspect rule. And: how can I refer to a syntactic
component_declaration when the component/declaration is inherited?

Suggested rewrite:
"It is illegal to specify any one of these aspects for an inherited component."

****************************************************************

From: Brad Moore
Sent: Sunday, May 15, 2011  2:54 PM

[The appropriate part of a longer message - Editor.]

> AI05-0229-1/09  Specifiable aspects
>     [Changes from phone meeting: moved xxx_components aspect to be array type only;
>      removed Preelaborable_Initialization (it will remain a pragma);added legality
>      rules to prevent various aspects from being specified on interfaces; added
>      change of pragma Convention to an aspect in predefined packages.]
>     Approve ___X___ Disapprove ______ Abstain _______

Editorial Comment: In the AI, in the wording section of the AI, there is
discussion stating the P_I is not appropriate as an aspect and will only be
available as a pragma. However, in the discussion section under the heading
"Pragmas that could be Boolean operational or Representational aspects:" it
still lists P_I.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 17, 2011  2:11 AM

...
> >  A representation pragma or library unit pragma that has a single
> > argument that  is a local_name may be specified by an
> > aspect_specification, with the entity  being the local_name. The
> > aspect_definition is expected to be of type Boolean.
> >  The expression shall be static.
>
> surely it is not a pragma that is specified. (and stacking the "that"s
> 3-deep is not nice).  Suggested Rewrite:
>
> Any aspect specified by a representation pragma or library unit pragma
> that has a local_name as its single argument may be specified by an
> aspect_specification, with the entity being the local_name. The
> aspect_definition is expected to be of type Boolean.  The expression
> shall be static.

Looks like an improvement to me, so I used it.

> >    If directly specified, the aspect_definition shall be a static expression.
> >     [Redundant: This aspect is never inherited;] ....
>
> Why is this redundant? 13.1 (15/1) says exactly the opposite.
> It is a representational aspect after all. Same comment for Inline and
> possibly others.

I presume you are talking about No_Return here (you didn't say). Anyway, that is
a subprogram aspect; 13.1(15/1) is only talking about type aspects and derived
types. There is no inheritance defined for other kinds of entities. As I
mentioned in another message, maybe there should have been, but in general we
don't need it for subprogram aspects.

Inline in particular is *not* inherited. And unlike No_Return, there is no
mechanism for it to be inherited. (Since it applies effectively to bodies, there
isn't any reason for it to be inherited, either.)

Similarly, preconditions and postconditions aren't inherited. (Class-wide ones
"apply" to descendants, but they aren't inherited either; this allows new ones
to be additively specified, which is what we want.)

> >  Replace C.6(10) with the following two paragraphs:
> >  If one of these aspects is specified for a component_declaration,
> > the declaration  shall not be inherited.
>
> Ambiguous wording. Can be read as an inheritance rule (hiding the
> component) rather than an aspect rule. And: how can I refer to a
> syntactic component_declaration when the component/declaration is
> inherited?
>
> Suggested rewrite:
> "It is illegal to specify any one of these aspects for an inherited
> component."

I think you were right with your first idea: it's not possible to specify an
aspect on an inherited component_declaration, because it is not syntactically
there. I was too literal in my translation of the old rules - that was a problem
when the name (alone) is specified in a pragma, but not when the entire syntax
has to appear (because that, by definition, is not inherited). So I just deleted
the sentence completely and fixed up the corresponding editor's note.

--------------------

I'm a bit surprised that you voted against this AI, as none of the technical
objections rise much beyond editorial questions. Was there some other objection
that you didn't voice??

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, May 17, 2011 12:16 PM

> I'm a bit surprised that you voted against this AI, as none of the technical
> objections rise much beyond editorial questions. Was there some other
> objection that you didn't voice??

Not at the time, but now I have. All of the pragmas turned into
respresentational aspects, none into operational aspects; the summary suggests
that there are operational ones, too. (A consequence of cut-and-paste or
deliberate?) Certainly Inline or No_Return do strike me as being perfectly
operational aspects (which, incidently, are specified as non-inherited, which
would justify the "Redundant"-phrases ;-))

The AI started out with me as an "Approve with comment", but we did not have
this category. Also, I was not sure whether the "Redundant" comments would not
merit further discussion as to why these were redundant. I still think that, for
representational attributes, they are not, because out of not specifying
inheritance of an aspect at all one cannot deduce non-inheritance, strictly
speaking. (Just because nothing is said about it, you cannot conclude that I am
not German.) But I guess, this is not the important discussion to have.

I would like to further discuss whether they are operational aspects.
A simple answer would be to make them operational aspects, along with many
others. In fact, apart from Storage_Size and most of the boolean attributes, the
listed pramas have the flavor of operational rather than representational
aspects.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May 17, 2011  2:30 PM

> > I'm a bit surprised that you voted against this AI, as none of the technical
> > objections rise much beyond editorial questions. Was there some
> > other objection that you didn't voice??
>
> Not at the time, but now I have. All of the pragmas turned into
> respresentational aspects, none into operational aspects; the summary
> suggests that there are operational ones, too. (A consequence of
> cut-and-paste or deliberate?)

I think the summary was written first; it should be fixed.

Anyway, the main issue is that Ada has no concept of "operational pragma", only
of "representation pragma". In order for any of these to be operational aspects,
the pragma classification would need to be changed, which would require a bunch
of extra wording in 13.1 (so that the important rules against duplication would
clearly apply).

This would have been doable, but I was trying (as usual) to make the minimum
changes here.

> Certainly Inline or No_Return do strike me as being perfectly
> operational aspects (which, incidently, are specified as
> non-inherited, which would justify the "Redundant"-phrases ;-))

No_Return is currently defined as a representation pragma. Changing it to
something else seemed like churn.

Inline is a library unit pragma, so it wouldn't have that problem. But
"inlining" seemed very representational to me (it has to do with the
representation of the body); the idea of operational aspects was for stuff that
didn't have a direct impact on the form of an entity. So this seems more
operational than representational.

> The AI started out with me as an "Approve with comment", but we did
> not have this category. Also, I was not sure whether the "Redundant"
> comments would not merit further discussion as to why these were
> redundant. I still think that, for representational attributes, they
> are not, because out of not specifying inheritance of an aspect at all
> one cannot deduce non-inheritance, strictly speaking.
> (Just because nothing is said about it, you cannot conclude that I am
> not German.) But I guess, this is not the important discussion to
> have.

My opinion is that if the RM doesn't explicitly state something, then it doesn't
exist. If we start "inferring" semantics from wording about other kinds of
entities, we are going to have a lot of trouble. Perhaps 13.1 should have a
sentence saying that there is no inheritance unless described explicitly, but
that seems to me to do without saying. We don't have to say that a float type is
not a descendant of type Integer! (Or more generally, we don't have to say that
a float type is not a descendant of any type other than root_real.) The meaning
of "inheritance" is exactly what the RM says it is, and nothing more.

It is a common problem in the wording that someone assumes "inheritance" or
"pragma applies" or terms like that are usable outside of their existing narrow
contexts. There have been a lot of fixes like that (Adam complaining about that
is what started AI05-0215-1, to take one recent example).

> I would like to further discuss whether they are operational aspects.
> A simple answer would be to make them operational aspects, along with
> many others. In fact, apart from Storage_Size and most of the boolean
> attributes, the listed pramas have the flavor of operational rather
> than representational aspects.

That might be, but they are almost all previously defined as representation
pragmas. And we don't have a concept of "operational pragma", so changing these
seemed like churn to me.

Also note that for types, "operational aspects" are allowed on private types,
"representational aspects" are not. For things like Priority, we don't want to
have to define rules for allowing them on private types, and I don't think we
want to muddle the rules by allowing some but not all operational aspects on
private types (that would require quite a bit of change in 13.1). So they too
end up as representational aspects.

As I mentioned in reply to Tucker, it would make a lot of sense to have
additional flavors of aspects (categorization aspects don't seem much like
either of the existing categories, for instance), but that is pretty complicated
to define and doesn't seem worth the effort.

****************************************************************

From: Tucker Taft
Sent: Monday, May  2, 2011  9:44 PM

[The appropriate part of a longer message - Editor.]

AI05-0190-1/11  Global storage pool controls
    [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
    Approve __X____ Disapprove ______ Abstain _______
   Comments:
     Should we move pragma Controlled to the obsolescent Annex?

****************************************************************

From: Randy Brukardt
Sent: Monday, May  2, 2011  10:32 PM

>      Should we move pragma Controlled to the obsolescent Annex?

AI05-0229-1 does that.

****************************************************************

From: Tucker Taft
Sent: Tuesday, May  3, 2011  2:04 PM

What I actually meant was to move the whole kit-and-kaboodle to Annex J.  That
is, move the Controlled aspect, pragma, etc. to Annex J.  In other words,
13.11.3 would disappear and reappear in Annex J.  Perhaps that is too radical?

Do *any* Ada compilers support the "Controlled" pragma/aspect?
Our Ada->Java-byte-code compiler supports garbage collection, but we don't have
any way of turning it off.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, May  3, 2011  2:51 PM

> What I actually meant was to move the whole kit-and-kaboodle to Annex
> J.  That is, move the Controlled aspect, pragma, etc. to Annex J.  In
> other words, 13.11.3 would disappear and reappear in Annex J.  Perhaps
> that is too radical?

It's pretty radical for the last minute.

OTOH, as a pragma, we don't even have to move it to annex J. If we don't want
the feature anymore, it can just go "poof"! And I agree that it doesn't do
anything useful (other than perhaps promise capabilities that can't really be
delivered in stock Ada - we don't have a permission to finalize early, so
anything that might be controlled cannot be garbage collected).

We have plenty of precident for "poof" in Ada 95 (pragma Memory_Size and
System_Name, also never implemented).

> Do *any* Ada compilers support the "Controlled" pragma/aspect?
> Our Ada->Java-byte-code compiler supports garbage collection, but we
> don't have any way of turning it off.

I don't know of any. That suggests "poof" is a good option...

****************************************************************

From: Randy Brukardt
Sent: Friday, May  6, 2011  12:47 AM

Tucker has suggested that we consider removing pragma Controlled from the core (and as a side-effect, not defining it as an aspect). He asks the question "Do *any* Ada compilers support the "Controlled" pragma/aspect?". I don't know of any.

As a pragma, we wouldn't even need to move this to Annex J; it could simply
disappear.

Probably the only real benefit of 13.11.3 is that it gets the term "garbage
collection" in the Standard and index, so that everyone can find out that Ada
doesn't have it. ;-)

Anyway, it is pretty late to consider this, but since I haven't yet done the
work to "aspectize" it in the draft Standard, we still can move the whole thing
to Annex J or delete it outright if we want.

So here's another straw poll:

Please rank these options from 1 to 4, with 1 being the most preferred and 4
being the least.

_______ Remove 13.11.3 (Pragma Controlled) completely from the standard.

_______ Move the entire contents of 13.11.3 to Annex J, do not make it an
	aspect.

_______ Move the entire contents of 13.11.3 to Annex J, but still make it an
	aspect.

_______ Make pragma Controlled into an aspect, move just the pragma to Annex J
	(the solution currently approved in AI05-0229-1).

****************************************************************

From: Randy Brukardt
Sent: Friday, May  6, 2011  12:47 AM

And here's my ballot:

...
> Please rank these options from 1 to 4, with 1 being the most preferred
> and 4 being the least.
>
> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the
> standard.
>
> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
> it an aspect.
>
> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
> make it an aspect.
>
> ___4____ Make pragma Controlled into an aspect, move just the pragma
> to Annex J (the solution currently approved in AI05-0229-1).

****************************************************************

From: Robert Dewar
Sent: Friday, May  6, 2011  4:25 AM

> Tucker has suggested that we consider removing pragma Controlled from
> the core (and as a side-effect, not defining it as an aspect). He asks
> the question "Do *any* Ada compilers support the "Controlled"
> pragma/aspect?". I don't know of any.

Not now, but it is always something that might be done in the future
>
> As a pragma, we wouldn't even need to move this to Annex J; it could
> simply disappear.
>
> Probably the only real benefit of 13.11.3 is that it gets the term
> "garbage collection" in the Standard and index, so that everyone can
> find out that Ada doesn't have it. ;-)
>
> Anyway, it is pretty late to consider this, but since I haven't yet
> done the work to "aspectize" it in the draft Standard, we still can
> move the whole thing to Annex J or delete it outright if we want.
>
> So here's another straw poll:
>
> Please rank these options from 1 to 4, with 1 being the most preferred
> and 4 being the least.

My preference isn't even here, which is do nothing at all. this is undoubtedly
what GNAT will do anyway.

I think it is plain silly to make this into an aspect, extra work for
implementations and the standard for absolutely no gain whatever.

Any of the solutions above has the disadvantage of being extra work I don't like
any of them

>>
>> __2_____ Remove 13.11.3 (Pragma Controlled) completely from the standard.

Well easy enough to implement, any implementation that followed suit would be
wasting its time, certainly we wouldn't bother in GNAT, though I guess this
technically would force us to add to the Annex M documentation.

>>
>> __1_____ Move the entire contents of 13.11.3 to Annex J, do not make
>> it an aspect.

Well that's zero work to implement and document, and I guess minimal work for
the standard effort, so if we have to choose one of these, this is the best

>>
>> __3_____ Move the entire contents of 13.11.3 to Annex J, but still
>> make it an aspect.

Better than 4 below, but still wastes everyones time

>>
>> __4_____ Make pragma Controlled into an aspect, move just the pragma
>> to Annex J (the solution currently approved in AI05-0229-1).

Wastes everyones time

****************************************************************

From: Jean-Pierre Rosen
Sent: Friday, May  6, 2011  5:21 AM

> Please rank these options from 1 to 4, with 1 being the most preferred
> and 4 being the least.
>
> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
>
> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
> it an aspect.
>
> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
> make it an aspect.
>
> ____4___ Make pragma Controlled into an aspect, move just the pragma
> to Annex J (the solution currently approved in AI05-0229-1).
>

I think pragma Controlled is actively harmful, I only saw it used by people who
did not understand its (none) effect, and who were expecting from it properties
that it did not ensure.

Making it into an aspect would be some kind of blessing that it does mean
something - which it doesn't.

****************************************************************

From: Bob Duff
Sent: Friday, May  6, 2011  5:53 AM

> And here's my ballot:
>
> ...
> > Please rank these options from 1 to 4, with 1 being the most
> > preferred and 4 being the least.
> >
> > ___1____ Remove 13.11.3 (Pragma Controlled) completely from the
> > standard.
> >
> > ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
> > it an aspect.
> >
> > ___3____ Move the entire contents of 13.11.3 to Annex J, but still
> > make it an aspect.
> >
> > ___4____ Make pragma Controlled into an aspect, move just the pragma
> > to Annex J (the solution currently approved in AI05-0229-1).

My vote is identical to Randy's, above.

I think the idea of (1) is that implementations will keep doing exactly what
they're doing, presumably keeping pragma Controlled as an impl-def pragma.

****************************************************************

From: John Barnes
Sent: Friday, May  6, 2011  5:55 AM

> Please rank these options from 1 to 4, with 1 being the most preferred
> and 4 being the least.
>
> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
>
> ____2___ Move the entire contents of 13.11.3 to Annex J, do not make
> it an aspect.
>
> _____3__ Move the entire contents of 13.11.3 to Annex J, but still
> make it an aspect.
>
> ____4___ Make pragma Controlled into an aspect, move just the pragma
> to Annex J (the solution currently approved in AI05-0229-1).

Yes, lets get rid of the wretched thing. That saves 4 lines in my book.

****************************************************************

From: Tucker Taft
Sent: Friday, May  6, 2011  7:34 AM

> Tucker has suggested that we consider removing pragma Controlled from
> the core (and as a side-effect, not defining it as an aspect). He asks
> the question "Do *any* Ada compilers support the "Controlled"
> pragma/aspect?". I don't know of any.
>
> As a pragma, we wouldn't even need to move this to Annex J; it could
> simply disappear.
>
> Probably the only real benefit of 13.11.3 is that it gets the term
> "garbage collection" in the Standard and index, so that everyone can
> find out that Ada doesn't have it. ;-)
>
> Anyway, it is pretty late to consider this, but since I haven't yet
> done the work to "aspectize" it in the draft Standard, we still can
> move the whole thing to Annex J or delete it outright if we want.
>
> So here's another straw poll:
>
> Please rank these options from 1 to 4, with 1 being the most preferred
> and 4 being the least.
>
> __1_____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
>
> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
> it an aspect.
>
> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
> make it an aspect.
>
> ___4____ Make pragma Controlled into an aspect, move just the pragma
> to Annex J (the solution currently approved in AI05-0229-1).

****************************************************************

From: Edmond Schonberg
Sent: Friday, May  6, 2011  9:46 AM

Get rid of it.

___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.

____2___ Move the entire contents of 13.11.3 to Annex J, do not make it an
aspect.

___3____ Move the entire contents of 13.11.3 to Annex J, but still make it an
aspect.

___4____ Make pragma Controlled into an aspect, move just the pragma to Annex
J (the solution currently approved in AI05-0229-1).

****************************************************************

From: Robert Dewar
Sent: Friday, May  6, 2011  11:26 AM

>> Please rank these options from 1 to 4, with 1 being the most
>> preferred and 4 being the least.
>>
>> ___1____ Remove 13.11.3 (Pragma Controlled) completely from the standard.
>>
>> ___2____ Move the entire contents of 13.11.3 to Annex J, do not make
>> it an aspect.
>>
>> ___3____ Move the entire contents of 13.11.3 to Annex J, but still
>> make it an aspect.
>>
>> ____4___ Make pragma Controlled into an aspect, move just the pragma
>> to Annex J (the solution currently approved in AI05-0229-1).
>>
>
> I think pragma Controlled is actively harmful, I only saw it used by
> people who did not understand its (none) effect, and who were
> expecting from it properties that it did not ensure.

OK, I find that a convincing argument, I change my vote to agree with the above

****************************************************************

From: Steve Baird
Sent: Friday, May  6, 2011  12:56 PM

Edmond Schonberg wrote:
> Get rid of it.

Agreed.

My vote is identical to Bob's, below.

Bob Duff wrote:
> My vote is identical to Randy's, above.

[Editor's note: the above is the unedited message. Any infinite recursion is
the responsibility of the original author. ;-)]

****************************************************************

From: Gary Dismukes
Sent: Friday, May  6, 2011  1:20 PM

I'm also fine with jettisoning it, and my vote matches others.

Looks like we have a true consensus.

****************************************************************

From: Brad Moore
Sent: Friday, May  6, 2011  7:03 PM

My vote is identical to Randy's and the others

****************************************************************

From: Bob Duff
Sent: Wednesday, May 11, 2011  11:54 AM

AI05-0229-1, Specifiable aspects says:

  ===pragma Interrupt_Priority, Priority  (the pragmas are to be obsolescent)

  [Editor's Note: I'd much prefer that there was only one aspect here, probably
  named "Base_Priority", but the rules about converting to subtype Any_Priority
  vs. to subtype Priority at evaluation time force two aspects. That's because
  these aspects are expressions that are evaluated when the task (or protected)
  object is elaborated, not values evaluated at the freezing point. Personally,
  I'd drop the two subtypes, but one presumes that there is some value to the
  bifrucation and in any case it is 30 years too late for that.]
                                    ^^^^^^^^ Less than 20 years --
                                             Interrupt_Priority
                                             was added in Ada 95.

The split was discussed heavily at the time, and everybody seemed to agree that
it's a good idea to flag interrupt priorities in a special way.  You don't want
to allow "pragma Priority(99)" if 99 just happens to be an interrupt level.

****************************************************************

From: Robert Dewar
Sent: Wednesday, May 11, 2011  11:54 AM

Right, I agree with that decision and disagree with Randy.

Btw, this silly (IMO) business of moving these pragmas to obsolescent status is
harmless (except for creating extra work) unless they are included in
No_Obsolescent_Features, in which case we have an unacceptable incompatibility
on our hands.

****************************************************************

From: Bob Duff
Sent: Thursday, May 12, 2011  8:31 AM

I was rather uncomfortable with this change.  I don't remember, but I probably
voted against it, or abstained.

It is implementation defined whether No_Obsolescent_Features gripes about these
pragmas.  A gratuitous non-portability, IMHO, but relatively harmless.

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  8:39 AM

Definitely gratuitous, but also irrelevant, for now implementation defined these
days mostly means "defined by GNAT" when it comes to Ada 2012. I suggest we NOT
include these changes in No_Obsolescent_Features for GNAT, there is no point
whatever in making an incompatible change. Is there really some other Ada 2012
compiler that strongly wants a different definition? If not, why not just define
it the way it is going to be, rather than leave this unnecessary non-portability
around.

To me, we have warnings on unrecognized pragmas in any case in all compilers, so
there is really no need for this to be included in NOF. If a compiler was so
stupid as to remove these pragmas in the future, or if the ARG was so stupid as
to remove them, then the compiler would warn.

To me obsolescent in practice means "defined, required, and will always be
required, but someone thinks it is a pity that this is the case" :-) :-). The
whole business of Annex J is gratuitous IMO.

****************************************************************

From: Bob Duff
Sent: Thursday, May 12, 2011  8:45 AM

>  I suggest we NOT include these changes in No_Obsolescent_Features for
> GNAT, ...

I was in charge of implementing AI05-0229-1 in GNAT, and that's exactly the
decision I made yesterday: I closed the ticket without modifying the behavior of
No_Obsolescent_Features.

The other part of AI05-0229-1 was to make lots of pragmas and attributes into
"aspects", which you (Robert) had already mostly done, and I added the rest.

****************************************************************

From: Randy Brukardt
Sent: Thursday, May 12, 2011  1:07 PM

...
> It is implementation defined whether No_Obsolescent_Features gripes
> about these pragmas.  A gratuitous non-portability, IMHO, but
> relatively harmless.

That was done because that was the way that the previous exceptions from the
restriction are handled. As a practical matter, everything in the annex should
be rejected when this restriction exists. We're giving a permission to vary from
that in a few specific cases, but no user should really be depending upon that
permission being used.

The entire point of the restriction is to allow people to ensure that they
aren't using old junk in new code; that clearly includes this set of pragmas.
The exception exists only because people currently using this restriction might
be impacted.

Really, this restriction (along with a number of other things) should work
differently depending on what language you are trying to enforce. And in this
case, what is restricted really should depend on whether the user wants to
restrict Ada 2005 Annex J (in existing code) or Ada 2012 Annex J (in new code)
-- and that's separate from which language version is being used to compile the
code. That clearly requires separate restrictions, something the language cannot
provide (sadly) because we're not allowed to talk about previous versions in the
Standard.

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  1:40 PM

> ...
>> It is implementation defined whether No_Obsolescent_Features gripes
>> about these pragmas.  A gratuitous non-portability, IMHO, but
>> relatively harmless.
>
> That was done because that was the way that the previous exceptions
> from the restriction are handled. As a practical matter, everything in
> the annex should be rejected when this restriction exists. We're
> giving a permission to vary from that in a few specific cases, but no
> user should really be depending upon that permission being used.

Well I don't see why not. This is implementation defined, so Annex M is clear on
the actual effect. For the vast majority (not all, but most) of our users, being
compatible with other Ada compilers is not an issue, so there is no reason for
them to follow Randy's advice here. The trouble is that if you make NOF reject
all obsolescent features, it is useless (due to some very injudicious IMO
inclusions in annex J).

> The entire point of the restriction is to allow people to ensure that
> they aren't using old junk in new code; that clearly includes this set
> of pragmas. The exception exists only because people currently using
> this restriction might be impacted.

No, it also exists because a reasonable coding style is to reject most of the
Annex J stuff, but not everything.

Actually to be fair I find the restriction pretty useless, given it rejects the
use of package ASCII. It's plain horrible to have to with the ISO package,
especially if you don't allow USE clauses.

In practice in GNAT we have a parallel mechanism -gnatwj, warn on obsolescent
features. the documentation says:

> In addition to the above cases, warnings are also generated for GNAT
> features that have been provided in past versions but which have been
> superseded (typically by features in the new Ada standard).
> For example, @code{pragma Ravenscar} will be flagged since its
> function is replaced by @code{pragma Profile(Ravenscar)}.
>
> Note that this warning option functions differently from the
> restriction @code{No_Obsolescent_Features} in two respects.
> First, the restriction applies only to annex J features.
> Second, the restriction does flag uses of package @code{ASCII}.

So actually I don't care that much if the pragmas are included, but including
the pragmas will surely make the restriction even more hopelessly unusable :-)

> Really, this restriction (along with a number of other things) should
> work differently depending on what language you are trying to enforce.
> And in this case, what is restricted really should depend on whether
> the user wants to restrict Ada 2005 Annex J (in existing code) or Ada
> 2012 Annex J (in new
> code) -- and that's separate from which language version is being used
> to compile the code. That clearly requires separate restrictions,
> something the language cannot provide (sadly) because we're not
> allowed to talk about previous versions in the Standard.

As I say, the issue to me is what it is sensible to include. I would find a
compiler that followed randy's advice to be plain annoying. Nothing to do with
compatibility issues.

****************************************************************

From: Randy Brukardt
Sent: Thursday, May 12, 2011  2:12 PM

...
> As I say, the issue to me is what it is sensible to include.
> I would find a compiler that followed randy's advice to be plain
> annoying.
> Nothing to do with compatibility issues.

Nothing new here. You've said this before (that you would find a compiler that
operates like I think a compiler should is annoying). Hopefully, you'll never
need to use Janus/Ada. ;-)

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  2:19 PM

Well actually, for us -gnatwj is much more what you want than the restriction. I
have never understood why people would want to say

    with Ada.Characters.Latin_1

    ...

    Put (Ada.Characters.Latin_1.LF);

instead of the so much more convenient

    Put (ASCII.LF);

SO I would never use the restriction anyway, so I don't really care what it does
:-)

The trouble is that it *sounds* reasonable to people to avoid obsolescent
features, so it is all to easy for a requirement of using the restriction to
creep into coding standards documents.

If such a requirement made people do major surgery on their programs to remove
all the pragmas and replace by aspects, that would constitute in effect a huge
extra barrier to the use of Ada 2012.

****************************************************************

From: Randy Brukardt
Sent: Thursday, May 12, 2011  2:38 PM

...
> The trouble is that it *sounds* reasonable to people to avoid
> obsolescent features, so it is all to easy for a requirement of using
> the restriction to creep into coding standards documents.

I agree with this, but trying to keep "coding standards" reasonable falls
outside of the perview of the ARG.

> If such a requirement made people do major surgery on their programs
> to remove all the pragmas and replace by aspects, that would
> constitute in effect a huge extra barrier to the use of Ada 2012.

Right, which is why I said that you need different restrictions for existing
code and for new code. Indeed, applying restrictions to existing code is silly
(I hope no coding standards are doing that), because it means a lot of rework
for no reason. One could imagine a No_Ada_2005_Obsolescent_Features restriction
for the purpose of existing systems, but that's outside of what the Standard can
do.

This is a major problem with most restrictions anyway (given that they apply to
the entire partition whether you want that or not). Restrictions that are mostly
style-related (like this one) should only apply to the current unit (it only
makes sense to use them in new code). But only the portability ones
(No_Implementation_Pragmas, etc.) get this right. Sigh.

****************************************************************

From: Bob Duff
Sent: Thursday, May 12, 2011  2:40 PM

Just a general comment on restrictions:  I can't get too excited about the exact
meaning of particular restrictions.  If the restriction is too restrictive,
don't use it.  If you want a restriction that's different from existing ones,
ask your vendor to provide one.

Pragma Restrictions is one of my favorite features, precisely because it allows
to much freedom to choose what you want for your own project.

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  2:42 PM

> ...
>> The trouble is that it *sounds* reasonable to people to avoid
>> obsolescent features, so it is all to easy for a requirement of using
>> the restriction to creep into coding standards documents.
>
> I agree with this, but trying to keep "coding standards" reasonable
> falls outside of the perview of the ARG.

Not in my opinion, creating annex J had consequences, and it is up to us to
anticipate and deal with these consequences.

>> If such a requirement made people do major surgery on their programs
>> to remove all the pragmas and replace by aspects, that would
>> constitute in effect a huge extra barrier to the use of Ada 2012.
>
> Right, which is why I said that you need different restrictions for
> existing code and for new code. Indeed, applying restrictions to
> existing code is silly (I hope no coding standards are doing that),
> because it means a lot of rework for no reason. One could imagine a
> No_Ada_2005_Obsolescent_Features restriction for the purpose of
> existing systems, but that's outside of what the Standard can do.

People apply coding standards to existing code all the time. Remember that 178B
requires you have a comprehebsive coding standard.

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  2:52 PM

> Just a general comment on restrictions:  I can't get too excited about
> the exact meaning of particular restrictions.  If the restriction is
> too restrictive, don't use it.  If you want a restriction that's
> different from existing ones, ask your vendor to provide one.

I think you probably miss my point. You are assuming that the programmers choose
the set of restrictions. That's not typically the case. Coding standards for
178B purposes are typically decided by a separate team who is not as sensible as
the Duff that wrote the above.

> Pragma Restrictions is one of my favorite features, precisely because
> it allows to much freedom to choose what you want for your own
> project.

You is simple in our world, not so simple in the real world

****************************************************************

From: Bob Duff
Sent: Thursday, May 12, 2011  3:21 PM

> I think you probably miss my point.

Not really.  My point is that it's not us Ada language designers placing
restrictions on people.  It's a programmer.  Or a project manager.  Or a
committee of beaurocrats.  Whatever.

And that's the beauty of pragma Restrictions.  We don't need to decide whether
(say) heap allocation is good or evil.  In fact, it's evil in some programs, but
not others.  So we can provide No_Heap_Alloc, and let people choose whether to
use it.  The fact that some folks will choose unwisely is not something I can do
anything about.

I'm well aware that idiotic coding conventions exist in the real world.  But I
can't fix that fact, so I don't worry about it.

****************************************************************

From: Robert Dewar
Sent: Thursday, May 12, 2011  3:34 PM

But you should have worried about it when you created annex J. It was an
inevitable and undesirable result of creating this annex that these annoying
coding standards exist.

You can't take actions without thought as to the real world consequences, we
really can't afford to be THAT far embedded in the ivory tower.

The restrictions we choose shape the way people will write coding standards!

****************************************************************

From: Bob Duff
Sent: Thursday, May 12, 2011  3:46 PM

> But you should have worried about it when you created annex J.

Annex J didn't turn out the way I intended.

And I think I've told you more than once:  I have (since Ada 9X
days) come around to your point of view -- we'd be better off without any Annex
J.

Also note that I didn't really support moving all those pragmas into Annex J.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, July  6, 2011  6:11 PM

Christoph Grein notes that the lists of 13.1(8.f-kk) contains a number of obsolescent
pragmas. This list gives type-related representation items, subtype-related ones, and
ones that are neither.

Replacing these pragmas with aspects directly won't work, because while pragmas are
representation items, an aspect_specification is not a representation item (although
it mught be used to specify a aspect of representation -- go figure).

The choices seem to be:
(1) Do nothing. The pragmas might be obsolescent, but they surely are still representation
items and still make sense in this list.

(2) Change the list headers to talk about aspects of representation rather than the
actual items. That would require dropping "pragma" and "clause" throughout the lists. This
would be the most correct and useful, but also is the most churn. At least this is an
AARM note so not much documentation of the changes is needed.

(3) Just change "pragma" to "aspect" here and be happy. But that seems to confuse aspects
with the means of setting them.

(4) Somehow change "representation item" to include aspect_specifications that set
representation aspects, and then change "pragma" to "aspect" as needed. This might actually
be the best solution, since not calling such things "representation items" seems unusual.
But we've been living with that for a long time now, and I don't think we need such a
change elsewhere. Since that would be a normative change, it would have the most risk.

(5) Delete this silly list (it is a pain to maintain, and it is of dubious utility --
especially given the new aspect index).

I'm leaning toward (1), but that probably is in part because it is the least work for me.
(2) would probably be the most accurate and least confusing, but (5) also is appealing.

Thoughts??

****************************************************************

From: Bob Duff
Sent: Wednesday, July  6, 2011  6:30 PM

> I'm leaning toward (1), but that probably is in part because it is the 
> least work for me. (2) would probably be the most accurate and least 
> confusing, but (5) also is appealing.

I more-or-less agree.  I lean toward (1).  I think this AARM junk is my handiwork, but
I wouldn't mind (5) too much -- just get rid of it if it's causing trouble.

****************************************************************

From: Tucker Taft
Sent: Wednesday, July  6, 2011  6:31 PM

I recommend you leave it basically as is, but perhaps add some general comment like
"(note that corresponding statements could be made about aspects and
aspect_specifications)".

****************************************************************

Questions? Ask the ACAA Technical Agent