CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/02/16 03:48:11 1.6
+++ ai05s/ai05-0229-1.txt 2011/03/17 07:05:01 1.7
@@ -1,7 +1,8 @@
-!standard 13.2(5) 11-02-15 AI05-0229-1/02
+!standard 13.2(5) 11-03-16 AI05-0229-1/03
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
+!standard J.15(0)
!standard K.1(0)
!class Amendment 10-10-25
!status work item 10-10-25
@@ -33,18 +34,31 @@
All specifiable operational and representation attributes may be
specified with an aspect_specification instead of an
-attribute_definition_clause (see 13.3). The attribute_designator is
-used for the aspect_mark.
+attribute_definition_clause (see 13.3).
-A representation pragma or program unit pragma that has a single argument that
+AARM Ramification: The name of the aspect is the same as that of the attribute
+(see 13.3), so the aspect_mark is the name of the attribute.
+[Editor's Note: 13.3(5/3), from AI05-0183-1; but we can't put paragraph numbers into
+AARM notes. We need this note here because this rule is far away in the standard.]
+
+A representation pragma or library unit pragma that has a single argument that
is a local_name may be specified by an aspect_specification, with the entity
-being the local_name and the aspect_mark being the same as the pragma name. The
-aspect_definition is expected to be of type Boolean. The expression shall be
-static with value True.
+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 note: The "=> True" part can be omitted by an existing rule
+[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.]
+be only a couple of paragraphs away from this one.
+
+This rule is mostly for the pragmas that are now moved to Annex J. We might consider
+moving this to Annex J as well - but we're not going to do that for the definition
+of representation pragmas in 13.1 (as it is too hard to extract) - so it OK to leave
+it here as well. Any preference??]
In addition, other operational and
representation aspects not associated with specifiable attributes may
@@ -54,38 +68,143 @@
Representation pragmas: (Covered by the general wording).
-===pragma Pack:
+===pragma Pack: (the pragma is to be obsolescent)
+Change the title of clause 13.2 to "Packed types". [Could have used "Aspect Pack"
+instead, but this seems more meaningful, and more like the inline clause. - RLB]
+
Change "packing" to "Pack" in 13.3(55.e), 13.3(72), 13.3(72.a), 13.1(7.g),
9.10(1/3), 9.10(1.c), 13.6(1).
[Note: We're only changing uses where "packing is specified" or the like.]
+
+Modify 13.2(1):
+
+Redundant[{The Pack aspect having the value True}[A pragma Pack] specifies that
+storage minimization should be the main criterion when selecting the representation
+of a composite type.]
+
+Delete 13.2(2-4). [Now in Annex J.]
+
+Replace 13.2(5):
+
+ For a full type declaration of a composite type, the following language-defined
+ representation aspect may be specified with an aspect_specification:
+ 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):
-Modify 13.2(5):
+{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].
-[A pragma Pack specifies the packing aspect of representation; ]
-{Pragma Pack is a representation pragmaRedundant[; it specifies the Pack aspect
-with the value True]. If the aspect Pack has the value True, }
-the type (or the extension part) is said to be packed. For a type extension, the
-parent part is packed as for the parent type, and [a pragma]{specifying} Pack
-causes packing only of the extension part.
+Modify 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 C.6(21):
-If [a pragma Pack applies to]{the Pack aspect has the value True for} a type any
+If [a pragma Pack applies to]{the Pack aspect is True for} a type any
of ...
+===pragma No_Return (the pragma is to be obsolescent)
-===pragma No_Return
+Change the title of clause 6.5.1 to "Non-returning procedures". [Could have used "Aspect No_Return" instead - RLB]
-6.5.1(2): No changes needed for No_Return.
+Modify 6.5.1(1/2):
-===pragma Controlled:
+{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].
-Modify 13.11.3(5):
-A pragma Controlled is a representation pragma[ that specifies the
-controlled aspect of representation].
+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 with an aspect_specification:
+ No_Return
+ The type of aspect No_Return is Boolean. When aspect No_Return is True for
+ an entity, the entity is said to be *non-returning*.
+
+ If directly specified, the aspect_definition shall be a static expression.
+ Redundant [This aspect is never inherited;] if not directly specified, the
+ aspect is False.
+
+Move 6.5.1(8/2) to this point (keeping the Static Semantics together).
+
+Replace 6.5.1(4/2): [Start of Legality Rules]
+
+Aspect No_Return shall not be specified for a null procedure nor an
+instance of a generic unit.
+
+Modify 6.5.1(10/2):
+procedure Fail(Msg : String)[;]; -- raises Fatal_Error exception
+ with No_Return => True;}
+[pragma No_Return(Fail);]
+ -- Inform compiler and reader that procedure never returns normally
+
+Modify 11.4.1(4/2):
+
+ procedure Raise_Exception(E : in Exception_Id;
+ Message : in String := ""){
+ with No_Return => True;
+ [pragma No_Return(Raise_Exception);]
+
+[This is the only use of No_Return in an Ada predefined package.]
+
+===pragma Controlled: (the pragma is to be obsolescent)
+
+Change the title of clause 13.11.3 to "Controlling Storage Reclamation". [Could have
+used "Aspect Controlled" instead, but this seems more meaningful, and more like the inline
+clause. - RLB]
+
+Modify 13.11.3(1/2):
+
+{Specifying aspect Controlled to have value True prevents}[Pragma Controlled is used to prevent]
+any automatic reclamation of storage (garbage collection) for the objects created by allocators
+of a given access type.
+
+Delete 13.11.3(2-4). [Now in Annex J.]
+
+Replace 13.11.3(5):
+
+ For a non-derived access type, the following language-defined
+ representation aspect may be specified with an aspect_specification:
+ Controlled
+ The type of aspect Controlled is Boolean.
+ If directly specified, the aspect_definition shall be a static expression.
+ If not specified (including by inheritance), the aspect is False.
+
+Modify 13.11.3(7):
+
+If {aspect Controlled is True}[a pragma Controlled is specified] for an access type with a standard
+storage pool, then garbage collection is not performed for objects in that pool.
+
+Modify 13.11.3(8):
+
+An implementation need not support garbage collection, in which case, {aspect Controlled}[a pragma
+Controlled] has no effect.
+
+
+** Unchanged - TBD **
===pragma Unchecked_Union:
Modify B.3.3(4/2):
@@ -94,16 +213,19 @@
Add Unchecked_Union to the index under "representation pragma".
+** Unchanged - TBD **
===pragma Discard_Names:
C.5(6): No changes needed for Discard_Names.
+** Unchanged - TBD **
===pragma Atomic, Atomic_Components, Independent,
Independent_Components, Volatile, Volatile_Components:
C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
Independent_Components, Volatile, Volatile_Components.
+** Unchanged - TBD **
===pragma Asynchronous:
Modify E.4.1(8):
@@ -138,73 +260,79 @@
See AI05-0243-1.
+** Unchanged - TBD **
===pragma All_Calls_Remote
Replace E.2.3(16):
A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect of the
-library unit to which it applies to the value True; the aspect can also be set
+library unit to which it applies to the value True; the aspect may also be set
by the aspect_specification of the library_item. If the All_Calls_Remote aspect
-of a library unit has the value True, the library unit shall be a remote call
+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]{has the value True for} a
+If [a pragma]{aspect} All_Calls_Remote [applies to]{is True for} a
given RCI library unit, ...
+** Unchanged - TBD **
===pragma Elaborate_Body
Replace 10.2.1(25):
-If the aspect Elaborate_Body has the value True for a declaration, then the
+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; the aspect can also be set
+library unit to which it applies to the value True; the aspect may also be set
by the aspect_specification of the library_item. If the Elaborate_Body aspect
-of a library unit has the value True, the body of the library unit is elaborated
+of a library unit is True, the body of the library unit is elaborated
immediately after its declaration.
-Program unit pragmas: (Somewhat covered by the general wording)
+===pragma Inline (the pragma is to be obsolescent)
-[Editor's note: We still need to recast these as aspects, and a particular
-kind of aspect in order to invoke the aspect-specific wording
-(particularly 13.1(9)). The general wording only provides the Boolean
-value and staticness rules.]
+Delete 6.3.2(2-4). [Now in Annex J.]
+
+Replace 6.3.2(5) with
-===pragma Inline
+ For a callable entity or a generic subprogram, the following language-defined
+ representation aspect may be specified with an aspect_specification:
+ Inline
+ The type of aspect Inline is Boolean. When aspect Inline is True for a
+ callable entity, indicates that inline expansion is
+ desired for all calls to that entity. When aspect Inline is True for a
+ generic subprogram, inline expansion is desired for all calls to all
+ instances of that generic subprogram.
-Modify 6.3.2(4):
+ 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.
-The pragma shall apply to{, or the Inline aspect shall be specified for,} one or
-more callable entities.
+Modify 6.3.2(6):
-Insert before 6.3.2(5):
+For each call, an implementation is free to follow or to ignore the recommendation
+{determined}[expressed] by the {Inline aspect}[pragma].
-A pragma Inline sets the Inline representation aspect of the program unit
-to which it applies to the value True; the aspect can also be set
-by the aspect_specification of the library_item.
+Delete 6.3.2(6.1/2).
-Modify 6.3.2(5):
+Delete AARM Notes 6.3.2(5.a-5.c) [but not 5.d], 6.3.2(6.b-c/2).
-If [a pragma Inline applies to]{aspect Inline has the value True for} a callable
-entity, this indicates that inline expansion is desired for all calls to that
-entity. If [a pragma Inline applies to]{aspect Inline has the value True for} a
-generic subprogram, this indicates that inline expansion is desired for all
-calls to all instances of that generic subprogram.
+Delete 6.3.2(7).
+
Other pragmas:
+** Unchanged - TBD **
===pragma Preelaborable_Initialization
Replace 10.2.1(11.6/2):
A pragma Preelaborable_Initialization sets the Preelaborable_Initialization
operational aspect of the type denoted by direct_name to the value True; the
-aspect can also be set by the aspect_specification of the declaration of a type.
+aspect may also be set by the aspect_specification of the declaration of a type.
The pragma shall only appear in the visible part of a package or generic
package. The aspect Preelaborable_Initialization shall only be specified for a
composite type declared in the visible part of a package or generic package.
@@ -214,11 +342,11 @@
Replace the middle three sentences of 10.2.1(11.7/3):
-If the aspect has the value True for a private type or a private extension, the
+If the aspect is True for a private type or a private extension, the
full view of the type shall have preelaborable initialization. If the aspect has
the value True for a protected type, the protected type shall not have entries,
and each component of the protected type shall have preelaborable
-initialization. If the aspect has the value True for any other composite type,
+initialization. If the aspect is True for any other composite type,
the type shall have preelaborable initialization.
Replace 10.2.1(11.8/3):
@@ -230,7 +358,7 @@
Preelaborable_Initialization aspect having the value True shall have
preelaborable initialization.
-AARM Ramification: This aspect can be specified on generic formal types that
+AARM Ramification: This aspect may be specified on generic formal types that
might be composite.
[Editor's Note: Better redo the AARM note in AI05-0183-1 to mention this!]
@@ -244,14 +372,15 @@
errors, so I went with the minimal change (even though it doesn't make much
sense logically).]
+** Unchanged - TBD **
===pragma Interrupt_Handler
Insert before C.3.1(7/3):
Static Semantics
-The Attach_Handler and Interrupt_Handler representation aspects can be specified
-on a protected procedure; the aspect_mark is the same as the name of the aspect.
+The Attach_Handler and Interrupt_Handler representation aspects may be specified
+on a parameterless protected procedure.
When the Interrupt_Handler aspect is specified the aspect_definition is expected
to be an expression of type Boolean. The expression shall be static with value
True. When the Attach_Handler aspect_mark is specified, the aspect_definition is
@@ -259,7 +388,7 @@
A pragma Interrupt_Handler specifies the Interrupt_Handler aspect for the
protected procedure handler_name to have the value True. A pragma Attach_Handler
-specifies the AttacheHandler aspect for the protected procedure handler_name to
+specifies the Attach_Handler aspect for the protected procedure handler_name to
have the value of the given expression Redundant[as evaluated at object creation
time].
@@ -268,23 +397,23 @@
Add after C.3.1(7/3):
If either the Attach_Hander or Interrupt_Handler aspect are specifed for a
-protected procedure, it shall have a parameterless profile, the corresponding
+protected 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.
+library-level declaration and shall not be declared within a generic body.
In addition to the places where Legality Rules normally apply (see 12.3), these
rules also apply in the private part of an instance of a generic unit.
Replace C.3.1(9):
-If a protected procedure has the aspect Interrupt_Handler with the value True,
-then the procedure can be attached dynamically, as a handler, to interrupts (see
+If the Interrupt_Handler aspect of a protected procedure is True,
+then the procedure may be attached dynamically, as a handler, to interrupts (see
C.3.2). Redundant[Such procedures are allowed to be attached to multiple
interrupts.]
Replace C.3.1(10):
-The value of the Attach_Handler aspect specifies an interrupt. As part of the
+The value of the Attach_Handler aspect identifies an interrupt. As part of the
initialization of the associated object, if the Attach_Handler aspect is
specified, the handler procedure is attached to the specified interrupt. A check
is made that the corresponding interrupt is not reserved. Program_Error is
@@ -336,12 +465,13 @@
Modify C.3.1(22):
-The Attach_Handler {aspect}[pragma] can provide static attachment of handlers to
+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.]
+** Unchanged - TBD **
===pragma Storage_Size
[Note: The existing attribute allows specification of Storage_Size for a task
@@ -406,7 +536,7 @@
Add after D.2.6(9/2):
-The Relative_Deadline representation aspect can be specified on a
+The Relative_Deadline representation aspect may be specified on a
task_type_declaration, a single_task_declaration, a subprogram_declaration. The
value of the aspect is an expression.
@@ -454,7 +584,7 @@
Static Semantics
-The CPU representation aspect can be specified on a task_type_declaration, a
+The CPU representation aspect may be specified on a task_type_declaration, a
single_task_declaration, a subprogram_declaration. The value of the aspect is an
expression.
@@ -490,7 +620,7 @@
Static Semantics
-The Priority and Interrupt_Priority representation aspects can be specified on a
+The Priority and Interrupt_Priority representation aspects may be specified on a
task_type_declaration, a single_task_declaration, a subprogram_declaration. The
value of the aspects is an expression.
@@ -509,8 +639,8 @@
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.
+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):
@@ -585,8 +715,9 @@
===pragma Implemented
-See AI05-0215-1. *** TBD: Ed Schonberg.
+See AI05-0215-1.
+** Unchanged - TBD **
===pragmas Convention, Export, Import:
Modify B.1(28) as follows:
@@ -607,7 +738,142 @@
defaults to Ada for a user-declared entity, unless specified otherwise
in this International Standard (see 6.3.1).]}
+===pragma Dispatching_Domain
+
+See AI05-0167-1.
+
+
+Add a new clause to Annex J:
+
+[Note: The subclauses will be rearranged in alphabetical order - at the last
+moment.]
+
+J.15 Aspect-related pragmas
+
+Pragmas can be used as an alternative to aspect_specifications to specify
+certain aspects.
+
+J.15.1 Pragma Pack
+
+Syntax
+
+The form of a pragma Pack 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 is a representation pragma that specifies that the Pack aspect
+(see 13.2) for the type denoted by *first_subtype_*local_name has the value True.
+
+J.15.2 Pragma Inline
+
+Syntax
+
+The form of a pragma Inline, which is a program unit pragma (see
+10.1.5), is as follows:
+
+ pragma Inline(name {, name});
+
+Legality Rules
+
+The pragma shall apply to one or more callable entities or generic
+subprograms.
+
+[Editor's Note: "apply" comes from the definition of program unit pragma.]
+
+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.
+
+AARM Ramification: Note that inline expansion is desired no matter
+what name is used in the call. This allows one to request inlining
+for only one of several overloaded subprograms as follows:
+
+package IO is
+ procedure Put(X : in Integer);
+ procedure Put(X : in String);
+ procedure Put(X : in Character);
+private
+ procedure Character_Put(X : in Character) renames Put;
+ pragma Inline(Character_Put);
+end IO;
+
+with IO; use IO;
+procedure Main is
+ I : Integer;
+ C : Character;
+begin
+ ...
+ Put(C); -- Inline expansion is desired.
+ Put(I); -- Inline expansion is NOT desired.
+end Main;
+
+Implementation Permissions
+
+An implementation may allow a pragma Inline that has an argument which
+is a direct_name denoting a subprogram_body of the same declarative_part.
+
+AARM Reason: This is allowed for Ada 83 compatibility. This is only a
+permission as this usage is considered obsolescent.
+
+AARM Discussion: We only need to allow this in declarative_parts,
+because a body is only allowed in another body, and these all have declarative_parts.
+
+NOTES
+
+The name in a pragma Inline may denote more than one entity in the
+case of overloading. Such a pragma applies to all of the denoted entities.
+
+J.15.3 Pragma No_Return
+
+Syntax
+
+The form of a pragma No_Return, which is a representation pragma (see 13.1),
+is as follows:
+
+ pragma No_Return(procedure_local_name{, procedure_local_name});
+
+Legality Rules
+
+Each procedure_local_name shall denote one or more procedures or generic procedures.
+Redundant[The procedure_local_name shall not denote a null procedure nor an instance
+of a generic unit.]
+
+Static Semantics
+
+Pragma No_Return specifies that the No_Return aspect (see 6.3.2) for each
+procedure denoted by each local_name given in the pragma has the value True.
+
+J.15.4 Pragma Controlled
+
+Syntax
+
+The form of a pragma Controlled is as follows:
+
+ pragma Controlled(first_subtype_local_name);
+
+Legality Rules
+
+The first_subtype_local_name of a pragma Controlled shall denote a non-derived access subtype.
+
+Static Semantics
+
+A pragma Controlled is a representation pragma that specifies the Controlled aspect (see 13.11.3)
+for the type denoted by *first_subtype_*local_name has the value True.
+
+
+*** Additional obsolescent pragmas here ***
+
+
+
+
Rearrange Annex K:
Annex K
@@ -2747,6 +3013,330 @@
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.
****************************************************************
Questions? Ask the ACAA Technical Agent