CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/09/29 06:34:03 1.21
+++ ai05s/ai05-0229-1.txt 2011/10/21 06:42:22 1.22
@@ -1,4 +1,4 @@
-!standard 1.1.3(17) 11-09-27 AI05-0229-1/13
+!standard 1.1.3(17) 11-10-14 AI05-0229-1/14
!standard 2.9(18)
!standard 2.8(29/2)
!standard 3.6.2(11)
@@ -229,6 +229,7 @@
!standard F(7)
!standard F.2(6)
!standard G(7)
+!standard J.9(3/2)
!standard J.15(0)
!standard J.15.1(0)
!standard J.15.2(0)
@@ -327,7 +328,7 @@
in the Specialized Needs Annex or is more limited in capability than that required
by the Annex. A program that attempts to use an unsupported capability of an Annex
shall either be identified by the implementation before run time or shall raise
-an exception at run time.
+an exception at run time.
Changes for individual pragmas:
@@ -571,8 +572,8 @@
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.
+all objects or components of that type. All atomic objects are considered to be
+specified as independently addressable.
Delete C.6(9/3) [Now in Annex J.]
@@ -619,7 +620,7 @@
Replace 9.10(15) with:
Aspect Atomic or aspect Atomic_Components may also be specified to ensure that
-certain reads and updates are sequential — see C.6.
+certain reads and updates are sequential — see C.6.
===pragma Asynchronous: (the pragma is to be obsolescent)
@@ -830,7 +831,7 @@
[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
+ The aspect Attach_Handler is an expression, which shall be of type
Interrupts.Interrupt_Id. [Redundant: This aspect is never inherited.]
Delete C.3.1(7/3). [Also in Annex J.]
@@ -949,7 +950,7 @@
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
+ The aspect Storage_Size is an expression, which shall be of
any integer type.
[Editor's note: I would have used the shorter wording "single task", but that
@@ -982,12 +983,18 @@
AARM Ramification: If the Storage_Size aspect is not specified for the type of
the task object, the value of the Storage_Size attribute is unspecified.
+Add to J.9(3/2):
+
+When the attribute is specified, the Storage_Size aspect
+is specified to be the value of the given expression.
+
Add after J.9(3/2):
AARM Ramification:
When this attribute is specified with an attribute_definition_clause, the
associated aspect is set to the value of the expression given in the
-attribute_definition_clause. This value is therefore the same for all objects of
+attribute_definition_clause, rather than the expression itself. This value
+is therefore the same for all objects of
the type; in particular, it is not re-evaluated when objects are created. This
is different than when the aspect is specified with an aspect_specification (see
13.3).
@@ -1014,10 +1021,10 @@
or subprogram, the following language-defined representation aspects may be
specified:
Priority
- The value of aspect Priority is an expression, which shall be of
+ The 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
+ The aspect Interrupt_Priority is an expression, which shall be of
type Integer.
[Editor's Note: See the comment about "single task" in Storage_Size.]
@@ -1119,7 +1126,7 @@
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
+ The aspect Relative_Deadline is an expression, which shall be of
type Real_Time.Time_Span.
[Editor's Note: See the comment about "single task" in Storage_Size.]
@@ -1165,7 +1172,7 @@
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
+ The aspect CPU is an expression, which shall be of
type System.Multiprocessors.CPU_Range.
[Editor's Note: See the comment about "single task" in Storage_Size.]
@@ -1376,7 +1383,7 @@
Implementation Advice
- If an implementation supports Export to a given language, then
+ If an implementation supports Export for a given language, then
it should also allow the main subprogram to be written in that
language. It should support some mechanism for invoking the
elaboration of the Ada library units included in the system, and for
@@ -1468,7 +1475,7 @@
An implicit declaration shall not have a completion. For any explicit declaration that is specified
to require completion, there shall be a corresponding explicit completion{, unless the declared
-entity is imported (see B.1)}.
+entity is imported (see B.1)}.
Replace 3.11.1(9) by:
@@ -1698,7 +1705,7 @@
Import, then it shall appear in the same declarative_part, package_specification, task_definition
or protected_definition as the declaration. For a library unit, it shall appear in the same
compilation, before any subsequent compilation_units other than pragmas. If the local_name
-denotes more than one entity, then the pragma Import is the completion of all of them.
+denotes more than one entity, then the pragma Import is the completion of all of them.
The external_name_string_expression and link_name_string_expression of a pragma Import
or Export shall be static.
@@ -1755,7 +1762,7 @@
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
+For the Interrupt_Handler pragma, the expected type for the expression is
Interrupts.Interrupt_Id (see C.3.2).
Legality Rules
@@ -1835,8 +1842,7 @@
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.
+declarative_part of a subprogram_body.
For a CPU pragma that appears in the declarative_part of a subprogram_body, the
expression shall be static.
@@ -1873,8 +1879,7 @@
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.
+or a protected_definition.
For a Priority pragma that appears in the declarative_part of a subprogram_body,
the expression shall be static, and its value shall be in the range of
@@ -1912,8 +1917,7 @@
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.
+or the declarative_part of a subprogram_body.
Static Semantics
@@ -2189,7 +2193,7 @@
in the Specialized Needs Annex or is more limited in capability than that required
by the Annex. A program that attempts to use an unsupported capability of an Annex
shall either be identified by the implementation before run time or shall raise
-an exception at run time.
+an exception at run time.
@dby
An implementation conforming to this International Standard may provide additional
aspects, attributes, library units, and pragmas. However, it shall not provide
@@ -2199,7 +2203,7 @@
in the Specialized Needs Annex or is more limited in capability than that required
by the Annex. A program that attempts to use an unsupported capability of an Annex
shall either be identified by the implementation before run time or shall raise
-an exception at run time.
+an exception at run time.
!corrigendum 2.8(18)
@@ -2229,12 +2233,12 @@
An implementation should normally represent multidimensional arrays in row-major order,
consistent with the notation used for multidimensional array aggregates (see 4.3.3).
However, if a @b<pragma> Convention(Fortran, ...) applies to a multidimensional
-array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
@dby
An implementation should normally represent multidimensional arrays in row-major order,
consistent with the notation used for multidimensional array aggregates (see 4.3.3).
However, if convention Fortran is specified for a multidimensional
-array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
+array type, then column-major order should be used instead (see B.5, “Interfacing with Fortran”).
!corrigendum 3.7(37/2)
@@ -2359,15 +2363,15 @@
@drepl
Of these four conventions, only Ada and Intrinsic are allowed as a @I<convention_>identifier
-in a @fa<pragma> Convention, Import, or Export.
+in a @fa<pragma> Convention, Import, or Export.
@dby
Of these four conventions, only Ada and Intrinsic are allowed as a @I<convention_>identifier
-in the specification of a Convention aspect.
+in the specification of a Convention aspect.
!corrigendum 6.3.2(2)
@ddel
-The form of a @fa<pragma> Inline, which is a program unit pragma (see 10.1.5), is as follows:
+The form of a @fa<pragma> Inline, which is a program unit pragma (see 10.1.5), is as follows:
!corrigendum 6.3.2(3)
@@ -2377,7 +2381,7 @@
!corrigendum 6.3.2(4)
@ddel
-The @fa<pragma> shall apply to one or more callable entities or generic subprograms.
+The @fa<pragma> shall apply to one or more callable entities or generic subprograms.
!corrigendum 6.3.2(5)
@@ -2385,7 +2389,7 @@
If a @fa<pragma> Inline applies to a callable entity, this indicates that inline expansion is
desired for all calls to that entity. If a @fa<pragma> Inline applies to a generic subprogram,
this indicates that inline expansion is desired for all calls to all instances of that generic
-subprogram.
+subprogram.
@dby
For a callable entity or a generic subprogram, the following language-defined
representation aspect may be specified:
@@ -2433,7 +2437,7 @@
@drepl
A @fa<pragma> No_Return indicates that a procedure cannot return normally; it may
-propagate an exception or loop forever.
+propagate an exception or loop forever.
@dby
Specifying aspect No_Return to have the value True
indicates that a procedure cannot return normally; it may propagate
@@ -2567,10 +2571,10 @@
@drepl
A @fa<pragma> Atomic or Atomic_Components may also be used to ensure that
-certain reads and updates are sequential — see C.6.
+certain reads and updates are sequential — see C.6.
@dby
Aspect Atomic or aspect Atomic_Components may also be specified to ensure
-that certain reads and updates are sequential — see C.6.
+that certain reads and updates are sequential — see C.6.
!corrigendum 10.1.4(7/2)
@@ -2687,7 +2691,7 @@
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.
+abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
@dby
If an exception is raised due to the failure of a language-defined check, then upon
reaching the corresponding @fa<exception_handler> (or the termination of the task,
@@ -2701,7 +2705,7 @@
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.
+abnormal, and certain subsequent uses of the object to be erroneous, as explained in 13.9.1.
!corrigendum 13.1(28/2)
@@ -2748,7 +2752,7 @@
@ddel
The @i<first_subtype_>@fa<local_name> of a @fa<pragma> Pack shall denote a
-composite subtype.
+composite subtype.
!comment %% 13.2(5) and 13.2(7) need changes here.
@@ -2799,7 +2803,7 @@
the following language-defined representation aspect may be specified:
@xhang<@xTerm<Storage_Size>
-The value of aspect Storage_Size is an @fa<expression>, which shall be of
+The aspect Storage_Size is an expression, which shall be of
any integer type.>
@s8<@i<Legality Rules>>
@@ -2812,7 +2816,7 @@
A @fa<pragma> Storage_Size is elaborated when an object of the type defined by the
immediately enclosing @fa<task_definition> is created. For the elaboration of a
@fa<pragma> Storage_Size, the @fa<expression> is evaluated; the Storage_Size attribute
-of the newly created task object is at least the value of the @fa<expression>.
+of the newly created task object is at least the value of the @fa<expression>.
@dby
@@ -3000,7 +3004,7 @@
@drepl
The expected type for a @i<string_>@fa<expression> in an interfacing pragma
-or in pragma Linker_Options is String.
+or in pragma Linker_Options is String.
@dby
The Import and Export aspects are of type Boolean.
@@ -3025,7 +3029,7 @@
@drepl
The type of an imported or exported object shall be compatible with the
-convention specified in the corresponding pragma.
+convention specified in the corresponding pragma.
@dby
The type of an imported or exported object shall be compatible with
the specified Convention aspect, if any.
@@ -3045,7 +3049,7 @@
@drepl
The external name and link name @i<string_>@fa<expression>s of a @fa<pragma>
Import or Export, and the @i<string_>@fa<expression> of a @fa<pragma>
-Linker_Options, shall be static.
+Linker_Options, shall be static.
@dby
The @fa<aspect_definition> (if any) used to directly specify an Import,
Export, External_Name, or Link_Name aspect shall be a static expression.
@@ -3071,7 +3075,7 @@
An interfacing pragma defines the convention of the entity denoted by the @fa<local_name>.
The convention represents the calling convention or representation convention of the entity.
For an access-to-subprogram type, it represents the calling convention of designated subprograms.
-In addition:
+In addition:
@dby
The Convention aspect represents the calling convention or
representation convention of the entity. For an access-to-subprogram
@@ -3123,7 +3127,7 @@
@drepl
It is the programmer's responsibility to ensure that the use of interfacing pragmas
-does not violate Ada semantics; otherwise, program execution is erroneous.
+does not violate Ada semantics; otherwise, program execution is erroneous.
@dby
It is the programmer's responsibility to ensure that the use of
interfacing aspects does not violate Ada semantics; otherwise,
@@ -3139,9 +3143,9 @@
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.
+time they are called.
@dby
-If an implementation supports Export to a given language, then
+If an implementation supports Export for a given language, then
it should also allow the main subprogram to be written in that
language. It should support some mechanism for invoking the
elaboration of the Ada library units included in the system, and for
@@ -3156,7 +3160,7 @@
@drepl
Automatic elaboration of preelaborated packages should be provided when @fa<pragma>
-Export is supported.
+Export is supported.
@dby
Automatic elaboration of preelaborated packages should be provided
when specifying Export as True is supported.
@@ -3215,11 +3219,11 @@
@drepl
An implementation shall support pragma Convention with a C @i<convention_>@fa<identifier> for a
C-eligible type (see B.1). An implementation shall support pragma Convention with a C_Pass_By_Copy
-@i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
+@i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
@dby
An implementation shall support specifying aspect Convention with a C @i<convention_>@fa<identifier>
for a C-eligible type (see B.1). An implementation shall support specifying aspect Convention
-with a C_Pass_By_Copy @i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
+with a C_Pass_By_Copy @i<convention_>@fa<identifier> for a C_Pass_By_Copy-eligible type.
!corrigendum B.3(62)
@@ -3260,13 +3264,13 @@
allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
corresponds to a common use of “char *” in C programs, and an object of this type can be passed
to a subprogram to which pragma Import(C,...) has been applied, and for which “char *” is the
-type of the argument of the C function.
+type of the argument of the C function.
@dby
The package Interfaces.C.Strings declares types and subprograms allowing an Ada program to
allocate, reference, update, and free C-style strings. In particular, the private type chars_ptr
corresponds to a common use of “char *” in C programs, and an object of this type can be passed
to a subprogram to which @ft<@b<with> Import => True, Convention => C> has been specified, and for
-which “char *” is the type of the argument of the C function.
+which “char *” is the type of the argument of the C function.
@@ -3324,21 +3328,21 @@
@drepl
The interfacing pragmas (see Annex B) should support interface to assembler; the default assembler
-should be associated with the convention identifier Assembler.
+should be associated with the convention identifier Assembler.
@dby
-The interfacing aspects (see Annex B) should support interface to assembler; the default assembler
-should be associated with the convention identifier Assembler.
+The support for interfacing aspects (see Annex B) should include interface to assembler; the
+default assembler should be associated with the convention identifier Assembler.
!corrigendum C.1(8)
@drepl
The implementation shall document the subprogram calling conventions associated with the convention
identifiers available for use with the interfacing pragmas (Ada and Assembler, at a minimum),
-including register saving, exception propagation, parameter passing, and function value returning.
+including register saving, exception propagation, parameter passing, and function value returning.
@dby
The implementation shall document the subprogram calling conventions associated with the convention
identifiers available for use with the Convention aspect (Ada and Assembler, at a minimum),
-including register saving, exception propagation, parameter passing, and function value returning.
+including register saving, exception propagation, parameter passing, and function value returning.
!comment %% C.3.1(1), C.3.1(2), C.3.1(3), C.3.1(4), C.3.1(5), and C.3.1(6) need changes here.
@@ -3349,7 +3353,7 @@
The Attach_Handler pragma is only allowed immediately within the @fa<protected_definition>
where the corresponding subprogram is declared. The corresponding
@fa<protected_type_declaration> or @fa<single_protected_declaration> shall be a
-library-level declaration.
+library-level declaration.
@dby
If either the Attach_Hander or Interrupt_Handler aspect are specifed for a
protected procedure, the corresponding
@@ -3408,14 +3412,14 @@
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.
+the previous handler is restored.
@dby
When a protected object is finalized, for any of its procedures that are attached to interrupts,
the handler is detached. If the handler was attached by a procedure in the Interrupts package
or if no user handler was previously attached to the interrupt, the default treatment is restored.
If the Attach_Handler aspect was specified and the most recently attached handler for the same interrupt
is the same as the one that was attached at the time the protected object was initialized,
-the previous handler is restored.
+the previous handler is restored.
!corrigendum C.3.1(14.1/1)
@@ -3425,25 +3429,25 @@
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.
+the protected object was initialized.
@dby
If the handlers for a given interrupt attached via aspect Attach_Handler are not attached and
detached in a stack-like (LIFO) order, program execution is erroneous. In particular, when
a protected object is finalized, the execution is erroneous if any of the procedures of the
protected object are attached to interrupts via aspect Attach_Handler and the most recently
attached handler for the same interrupt is not the same as the one that was attached at the time
-the protected object was initialized.
+the protected object was initialized.
!corrigendum C.3.1(17)
@drepl
When the pragmas Attach_Handler or Interrupt_Handler apply to a protected procedure, the
implementation is allowed to impose implementation-defined restrictions on the corresponding
-@fa<protected_type_declaration> and @fa<protected_body>.
+@fa<protected_type_declaration> and @fa<protected_body>.
@dby
When the aspects Attach_Handler or Interrupt_Handler are specified for a protected procedure, the
implementation is allowed to impose implementation-defined restrictions on the corresponding
-@fa<protected_type_declaration> and @fa<protected_body>.
+@fa<protected_type_declaration> and @fa<protected_body>.
!corrigendum C.3.1(19)
@@ -3452,7 +3456,7 @@
pragmas are allowed to be used for other, implementation defined, forms of interrupt handlers.
@dby
Notwithstanding what this subclause says elsewhere, the Attach_Handler and Interrupt_Handler
-aspects are allowed to be used for other, implementation defined, forms of interrupt handlers.
+aspects are allowed to be used for other, implementation defined, forms of interrupt handlers.
!corrigendum C.3.1(22)
@@ -3775,13 +3779,13 @@
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.
+the PCS.
@dby
If aspect All_Calls_Remote is True for a given RCI library unit, then the implementation shall
route any call to a subprogram of the RCI unit 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.
+the PCS.
!corrigendum E.4.1(0)
@@ -3812,7 +3816,7 @@
@drepl
A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the
-type-related @i<asynchronous> aspect of the type.
+type-related @i<asynchronous> aspect of the type.
@dby
For a remote procedure, the following language-defined
representation aspect may be specified:
@@ -3847,13 +3851,13 @@
an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma
Asynchronous applies to a remote access-to-class-wide type, then a dispatching call on a procedure
with a controlling operand designated by a value of the type is asynchronous if the formal parameters
-of the procedure are all of mode @b<in>.
+of the procedure are all of mode @b<in>.
@dby
A remote call is @i<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 @b<in>.
+of the procedure are all of mode @b<in>.
!corrigendum F(7)
@@ -3863,13 +3867,13 @@
the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
-written in that language.
+written in that language.
@dby
If COBOL (respectively, C) is widely supported in the target environment, implementations supporting
the Information Systems Annex should provide the child package Interfaces.COBOL (respectively,
Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively,
C) for the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
-written in that language.
+written in that language.
!corrigendum F.2(6)
@@ -3905,15 +3909,26 @@
the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs
-written in that language.
+written in that language.
@dby
If Fortran (respectively, C) is widely supported in the target environment, implementations supporting
the Information Systems Annex should provide the child package Interfaces.Fortran (respectively,
Interfaces.C) specified in Annex B and should support a convention_identifier of Fortran (respectively,
C) for the Convention aspect (see Annex B), thus allowing Ada programs to interface with programs
-written in that language.
+written in that language.
+!corrigendum J.9(3/2)
+
+@drepl
+Storage_Size may be specified for a task first subtype that is not an interface via an
+@fa<attribute_definition_clause>.
+@dby
+Storage_Size may be specified for a task first subtype that is not an interface via an
+@fa<attribute_definition_clause>. When the attribute is specified, the Storage_Size aspect
+is specified to be the value of the given @fa<expression>.
+
+
!corrigendum J.15(0)
@dinsc
@@ -4056,7 +4071,7 @@
@fa<task_definition>, or @fa<protected_definition> as the declaration. For a library unit,
it shall appear in the same @fa<compilation>, before any subsequent @fa<compilation_unit>s other
than @fa<pragma>s. If the @fa<local_name>
-denotes more than one entity, then the @fa<pragma> Import is the completion of all of them.
+denotes more than one entity, then the @fa<pragma> Import is the completion of all of them.
The @i<external_name_string_>@fa<expression> and @i<link_name_string_>@fa<expression> of a
@fa<pragma> Import or Export shall be static.
@@ -4202,8 +4217,7 @@
@s8<@i<Legality Rules>>
A CPU pragma is allowed only immediately within a @fa<task_definition>, or the
-@fa<declarative_part> of a @fa<subprogram_body>. At most one such pragma
-shall appear within a given construct.
+@fa<declarative_part> of a @fa<subprogram_body>.
For a CPU pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body>,
the @fa<expression> shall be static.
@@ -4241,8 +4255,7 @@
A Priority pragma is allowed only immediately within a @fa<task_definition>, a
@fa<protected_definition>, or the @fa<declarative_part> of a @fa<subprogram_body>.
An Interrupt_Priority pragma is allowed only immediately within a @fa<task_definition>
-or a @fa<protected_definition>. At most one such pragma shall appear within a given
-construct.
+or a @fa<protected_definition>.
For a Priority pragma that appears in the @fa<declarative_part> of a @fa<subprogram_body,>
the @fa<expression> shall be static, and its value shall be in the range of
@@ -4286,8 +4299,7 @@
@s8<@i<Legality Rules>>
A Relative_Deadline pragma is allowed only immediately within a @fa<task_definition>
-or the @fa<declarative_part> of a @fa<subprogram_body>. At most one such pragma shall
-appear within a given construct.
+or the @fa<declarative_part> of a @fa<subprogram_body>.
@s8<@i<Static Semantics>>
@@ -6593,8 +6605,8 @@
From: Bob Duff
Sent: Tuesday, March 15, 2011 12:39 PM
-> In the minutes, you asked me to "send a complete list of aspects". I
-> presume this was a tactic to avoid doing the work on the Annex for as
+> In the minutes, you asked me to "send a complete list of aspects". I
+> presume this was a tactic to avoid doing the work on the Annex for as
> long as possible. :-)
;-)
@@ -6602,9 +6614,9 @@
Actually, it was a tactic to avoid doing the hard work of tracking down all the aspect names.
>...Sorry, but that tactic is now expired.
->
-> Attached find a listing of the 65 specifiable aspects that I was able
-> to find. There might be some that I forgot about - feel free to tell
+>
+> Attached find a listing of the 65 specifiable aspects that I was able
+> to find. There might be some that I forgot about - feel free to tell
> me if I missed something obvious.
OK, thanks. Here's the wording you requested. It's intentionally very informal.
@@ -6869,9 +6881,9 @@
From: Robert Dewar
Sent: Tuesday, March 15, 2011 2:51 PM
-> OK, thanks. Here's the wording you requested. It's intentionally
-> very informal. Anybody who nitpicks it in a language-lawyerly way
-> will be summarily shot. For once in our lives, we can place
+> OK, thanks. Here's the wording you requested. It's intentionally
+> very informal. Anybody who nitpicks it in a language-lawyerly way
+> will be summarily shot. For once in our lives, we can place
> understandability over correctness!
Here here!
@@ -6910,9 +6922,9 @@
From: Randy Brukardt
Sent: Tuesday, March 15, 2011 5:53 PM
-> I left out "coding" and "record layout", because these are
-> neither specifiable via an aspect clause, nor queryable.
-> Programmers have no reason to care about these; they exist
+> I left out "coding" and "record layout", because these are
+> neither specifiable via an aspect clause, nor queryable.
+> Programmers have no reason to care about these; they exist
> only to feed into the rule about not specifying the same thing twice.
We discussed this explicitly in St. Pete Beach, and came to the opposite
@@ -6929,8 +6941,8 @@
don't see it in your above explanation...
> You listed Write'Class and friends. I think you mean Class'Write.
-> Anyway, I left these 4 out. I figure, if anybody wants to
-> look them up, they'll look up 'Write, and be sent to the
+> Anyway, I left these 4 out. I figure, if anybody wants to
+> look them up, they'll look up 'Write, and be sent to the
> right section.
Since there is no declaration for T'Class, in order to specify the attribute
@@ -6941,29 +6953,29 @@
This sounds like a candidate for an early Ada 2012 Binding Interpretation.
-> These are all formatted uniformly, so you can easily massage
-> them with editor macros if you like. Separated by blank
-> lines. First line is the section number where you should
-> insert the macro call. Second line is the first three args.
+> These are all formatted uniformly, so you can easily massage
+> them with editor macros if you like. Separated by blank
+> lines. First line is the section number where you should
+> insert the macro call. Second line is the first three args.
> Third and subsequent lines are the wording.
->
-> Let me know if you want me to do any such massaging -- I'm
-> pretty good with Emacs macros. Just tell me how you want
+>
+> Let me know if you want me to do any such massaging -- I'm
+> pretty good with Emacs macros. Just tell me how you want
> them formatted.
Doesn't look necessary. I'll probably spend a lot longer implementing the
commands and the annex output than putting these into the draft. Most of the
work will be finding the right place to drop these in.
-> One aspect (Implemented) has no section number. Didn't we
+> One aspect (Implemented) has no section number. Didn't we
> rename this one, by the way?
See the messages from Ed later today.
-
-> I included the explanatory text from your email after the
+
+> I included the explanatory text from your email after the
> section numbers.
->
-> I don't know what "chgaspectdesc" means, but that's the macro
+>
+> I don't know what "chgaspectdesc" means, but that's the macro
> name you told me to use.
"chg" - Change; this abbreviation was inherited from the Scribe version.
@@ -6992,13 +7004,13 @@
From: Bob Duff
Sent: Tuesday, March 15, 2011 6:55 PM
-> We discussed this explicitly in St. Pete Beach, and came to the
+> We discussed this explicitly in St. Pete Beach, and came to the
> opposite
> conclusion:
->
-> "Do we want aspects in the aspect annex that can't be specified with
-> aspect_specification? For instance, enumeration rep clause. Yes, but
-> we'll need to add wording to say that you use an enumeration rep
+>
+> "Do we want aspects in the aspect annex that can't be specified with
+> aspect_specification? For instance, enumeration rep clause. Yes, but
+> we'll need to add wording to say that you use an enumeration rep
> clause rather than an aspect_specification."
Oh, sorry, I don't remember that, and neglected to consult the minutes.
@@ -7018,10 +7030,10 @@
Text=[Layout of record components. Specified by a
record_representation_clause, not by an aspect_specification.]}
-> Since there is no declaration for T'Class, in order to specify the
-> attribute using an aspect we would need some other method. Given that
-> we already have Pre'Class, it would make sense to also have
-> Write'Class. But I admit that we would need wording to support this;
+> Since there is no declaration for T'Class, in order to specify the
+> attribute using an aspect we would need some other method. Given that
+> we already have Pre'Class, it would make sense to also have
+> Write'Class. But I admit that we would need wording to support this;
> in the absence of that wording, you can only specify these via attribute
> definition clauses.
@@ -7032,18 +7044,18 @@
From: Robert Dewar
Sent: Tuesday, March 15, 2011 6:09 PM
->> I left out "coding" and "record layout", because these are neither
+>> I left out "coding" and "record layout", because these are neither
>> specifiable via an aspect clause, nor queryable.
->> Programmers have no reason to care about these; they exist only to
+>> Programmers have no reason to care about these; they exist only to
>> feed into the rule about not specifying the same thing twice.
>
-> We discussed this explicitly in St. Pete Beach, and came to the
+> We discussed this explicitly in St. Pete Beach, and came to the
> opposite
> conclusion:
>
-> "Do we want aspects in the aspect annex that can't be specified with
-> aspect_specification? For instance, enumeration rep clause. Yes, but
-> we'll need to add wording to say that you use an enumeration rep
+> "Do we want aspects in the aspect annex that can't be specified with
+> aspect_specification? For instance, enumeration rep clause. Yes, but
+> we'll need to add wording to say that you use an enumeration rep
> clause rather than an aspect_specification."
Why can't we have
@@ -7090,11 +7102,11 @@
Sent: Tuesday, March 15, 2011 6:45 PM
> Why can't we have
->
+>
> type A is (B, C, D) with
> Enum_Rep => (B => 1, C => 10, D => 20);
->
-> Looks fine to me, I think we should allow anything that has the
+>
+> Looks fine to me, I think we should allow anything that has the
> syntactic form of an expression, just as we do for pragmas.
If you add that to the RM, next thing you know, ARG will move the
@@ -7112,7 +7124,7 @@
> I think the above is probably valid as an impl-def aspect.
> But I think it's a waste of energy to implement it.
-> And the other one is record reps -- I don't want to think about how to
+> And the other one is record reps -- I don't want to think about how to
> turn those into aspect clauses.
Well the easiest thing is to just allow exactly the same syntax, instead of
@@ -7131,11 +7143,11 @@
From: Bob Duff
Sent: Tuesday, March 15, 2011 8:51 PM
-> > OK, thanks. Here's the wording you requested. It's intentionally
-> > very informal. Anybody who nitpicks it in a language-lawyerly way
-> > will be summarily shot. For once in our lives, we can place
+> > OK, thanks. Here's the wording you requested. It's intentionally
+> > very informal. Anybody who nitpicks it in a language-lawyerly way
+> > will be summarily shot. For once in our lives, we can place
> > understandability over correctness!
->
+>
> Here here!
Thank you, but I think you mean:
@@ -8304,8 +8316,8 @@
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
+> 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
@@ -8343,14 +8355,14 @@
...
> We have Annex L Language Defined Pragmas.
->
-> Since aspects now replace many pragmas, shouldn't that now be Annex L
+>
+> Since aspects now replace many pragmas, shouldn't that now be Annex L
> Language Defined Aspects and Pragmas?
No.
-
+
> It's difficult to see which aspects are allowed for a given declaration.
-> For instance, which aspects are allowed on generic_instantiation? This
+> For instance, which aspects are allowed on generic_instantiation? This
> annex should help solve this problem.
Right idea, wrong annex, and the need was long since realized by the ARG (see
@@ -8379,7 +8391,7 @@
is either as specified in the Specialized Needs Annex or is more limited in capability
than that required by the Annex. A program that attempts to use an unsupported capability
of an Annex shall either be identified by the implementation before run time or shall
-raise an exception at run time.
+raise an exception at run time.
I think it goes without saying that we intend this to apply to specifiable aspects that
are defined in Annexes as well as the constructs named. Other than that we in fact
@@ -8452,9 +8464,9 @@
Sent: Thursday, August 11, 2011 1:01 AM
...
-> Should the wording be removed (along with the new note)? An
-> implementation-defined pragma can do whatever it wants, and surely we
-> don't need wording in the Standard just to support those as
+> Should the wording be removed (along with the new note)? An
+> implementation-defined pragma can do whatever it wants, and surely we
+> don't need wording in the Standard just to support those as
> completions.
I may have answered my own question. I hadn't noticed (or remembered)
@@ -8470,17 +8482,506 @@
Sent: Thursday, August 11, 2011 6:41 AM
> I may have answered my own question. I hadn't noticed (or remembered)
-> 2.8(18) when I wrote that; we're surely not dropping that advice
-> [although I dropped the part about pragma Import, since it is a lie
+> 2.8(18) when I wrote that; we're surely not dropping that advice
+> [although I dropped the part about pragma Import, since it is a lie
> now] and it would be kinda weird to explicitly allow such pragmas but
> never say what they mean.
->
+>
> So I think I already have this right.
I agree. Let's not (again!) get into an argument about the kludgery in and
near 2.8(18).
If it ain't broke, don't fix it. Very broke.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 12, 2011 10:30 AM
+
+[From Tucker's editorial review:]
+
+13.3 65.a/3:
+
+ To be honest: This definition somewhat conflicts with the
+ "automatic" one for the obsolescent attribute Storage_Size (which
+ can be specified). We intend for the above definition to supercede
+ that "automatic" definition for this attribute.
+
+ This is bizarre. I highly recommend we drop Storage_Size from the
+ obsolescent annex, as these two features now conflict badly. It should
+ no longer be possible to specify Storage_Size with an attribute
+ definition clause, or if it is, it should be *exactly* equivalent to
+ specifying the aspect with an aspect specification clause.
+
+J.9 The Storage_Size attribute
+
+ As mentioned above (13.3, 65.a/3), I believe this attribute should be
+ removed from the language since we now have a specifiable aspect with
+ the same name and a different meaning.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, September 30, 2011 11:57 PM
+
+This *is* bizarre, but dropping the attribute specification would be highly incompatible.
+At least one Ada user I know really well (me) only uses this form because he hates the
+pragmas so much that he never implemented them. Dropping this attribute_definition_clause
+would break all of my programs (including Claw). I doubt I'm the only one.
+
+And forcing the semantics to work like the old pragma and the new aspect isn't practical
+-- the aspect specifies an *expression*, that is evaluated per-object, while an
+attribute_definition_clause specifies a *value*, that is evaluated at the place of the
+clause (and thus is evaluated once per-type -- that was the original reason for introducing
+the pragma). Besides requiring a new mechanism that would only be used for this one
+attribute, it also would introduce an inconsistency (evaluating the expression multiple
+times in different places might get different answers than the current evaluation rules,
+potentially causing significant headaches).
+
+The bizarre behavior seemed like the least evil of the options; it doesn't break any
+existing code, and just requires that the implementer treat the obsolescent attribute
+separately from the aspect. That doesn't seem too hard to do.
+
+There might be a way to unify these without breaking everything, if we could somehow make
+the attribute_definition_clause provide an expression that is the evaluated value of the
+attribute. (That is, the evaluation would occur at the point of the
+attribute_definition_clause, then that value would become the expression that the aspect
+evaluates per-object - which obviously would have not effect.) I don't have any idea how
+to accomplish that; they would have to be some weird wording somewhere that existed only
+for the obsolescent attribute. If you want to take a stab at it, please feel free (but it
+just makes my head hurt :-).
+
+> J.9 The Storage_Size attribute
+>
+> As mentioned above (13.3, 65.a/3), I believe this attribute should be
+> removed from the language since we now have a specifiable aspect with
+> the same name and a different meaning.
+
+See above.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 1, 2011 7:53 AM
+
+...
+> This *is* bizarre, but dropping the attribute specification would be
+> highly incompatible. At least one Ada user I know really well (me)
+> only uses this form because he hates the pragmas so much that he never implemented them.
+> Dropping this attribute_definition_clause would break all of my
+> programs (including Claw). I doubt I'm the only one.
+
+Do you ever use variables in your attribute specifications, or are they
+always literals or constants?
+
+> And forcing the semantics to work like the old pragma and the new
+> aspect isn't practical -- the aspect specifies an *expression*, that
+> is evaluated per-object, while an attribute_definition_clause
+> specifies a *value*, that is evaluated at the place of the clause (and
+> thus is evaluated once per-type
+> -- that was the original reason for introducing the pragma). Besides
+> requiring a new mechanism that would only be used for this one
+> attribute, it also would introduce an inconsistency (evaluating the
+> expression multiple times in different places might get different
+> answers than the current evaluation rules, potentially causing significant headaches).
+
+I see no problem if we require that the attribute specification use only constants
+or literals. Then we equate it with the aspect specification, and we know it
+evaluates to the same value everywhere.
+
+> The bizarre behavior seemed like the least evil of the options; it
+> doesn't break any existing code, and just requires that the
+> implementer treat the obsolescent attribute separately from the
+> aspect. That doesn't seem too hard to do.
+
+I don't agree with that. I think it is a mess as it is now. People will have
+a hard enough time with the new "aspect" concepts, and it will really help if,
+when thinking about attributes, they are interchangeable.
+If somehow specifying Storage_Size with an attribute definition clause is
+significantly different than specifying it with an aspect clause, the poor user
+will really be confused, and almost certainly implementors will mess it up one
+way or the other.
+
+> There might be a way to unify these without breaking everything, if we
+> could somehow make the attribute_definition_clause provide an
+> expression that is the evaluated value of the attribute. (That is, the
+> evaluation would occur at the point of the
+> attribute_definition_clause, then that value would become the
+> expression that the aspect evaluates per-object - which obviously
+> would have not effect.) I don't have any idea how to accomplish that;
+> they would have to be some weird wording somewhere that existed only
+> for the obsolescent attribute. If you want to take a stab at it, please feel free
+> (but it just makes my head hurt :-).
+
+I think we could require the expression given in the Storage_Size attribute
+definition clause to involve only constants and literals.
+We say something similar about address clauses for objects, I believe.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 10, 2011 8:56 PM
+
+...
+> Do you ever use variables in your attribute specifications, or are
+> they always literals or constants?
+
+I think they're usually constants. But that's irrelevant (see below).
+
+> > And forcing the semantics to work like the old pragma and the new
+> > aspect isn't practical -- the aspect specifies an *expression*, that
+> > is evaluated per-object, while an attribute_definition_clause
+> > specifies a *value*, that is evaluated at the place of the clause
+> > (and thus is evaluated once per-type
+> > -- that was the original reason for introducing the pragma). Besides
+> > requiring a new mechanism that would only be used for this one
+> > attribute, it also would introduce an inconsistency (evaluating the
+> > expression multiple times in different places might get different
+> > answers than the current evaluation rules, potentially causing
+> > significant headaches).
+>
+> I see no problem if we require that the attribute specification use
+> only constants or literals. Then we equate it with the aspect
+> specification, and we know it evaluates to the same value everywhere.
+
+I know of nothing like this anywhere else in the Ada standard. We have rules
+that require static expressions, but that would prevent using the storage size
+of some other task (T'Storage_Size) -- which would be incompatible again. And
+creating a rule just for this case seems silly.
+
+> > The bizarre behavior seemed like the least evil of the options; it
+> > doesn't break any existing code, and just requires that the
+> > implementer treat the obsolescent attribute separately from the
+> > aspect. That doesn't seem too hard to do.
+>
+> I don't agree with that. I think it is a mess as it is now.
+> People will have a hard enough time with the new "aspect"
+> concepts, and it will really help if, when thinking about attributes,
+> they are interchangeable.
+> If somehow specifying Storage_Size with an attribute definition clause
+> is significantly different than specifying it with an aspect clause,
+> the poor user will really be confused, and almost certainly
+> implementors will mess it up one way or the other.
+
+But this is wrong: the attributes and aspects are subtly different, and that
+has nothing to do with this attribute. The point at which the expressions are
+resolved and evaluated differ for all aspect_specifications vs.
+attribute_definition_clauses, and that can change the behavior even for supposedly
+simple aspects like Size. We discussed that extensively in the past.
+
+The same is true here. It *appears* to be more significant, but would be only in
+pathological programs. After all, no per-object expressions can appear in the
+attribute_definition_clause, and including function calls or variables that change
+values when evaluated is just plain weird. So, in practice, the result will be the
+same either way.
+
+As far as implementations go, the implementation of aspect_specifications and
+attribute_definition_clauses is similar, but the implementer has to be very careful
+about resolution and evaluation points. I expect everybody will make mistakes in this
+area -- but that has nothing whatsoever to do with Storage_Size; it applies to every
+aspect that can also be specified by an attribute. (Recall that Robert said that
+implementing aspect_specifications correctly was a lot of work, there is a lot
+less reuse possible than appears on the surface.)
+
+> > There might be a way to unify these without breaking everything, if
+> > we could somehow make the attribute_definition_clause provide an
+> > expression that is the evaluated value of the attribute. (That is,
+> > the evaluation would occur at the point of the
+> > attribute_definition_clause, then that value would become the
+> > expression that the aspect evaluates per-object - which obviously
+> > would have not effect.) I don't have any idea how to accomplish
+> > that; they would have to be some weird wording somewhere that
+> > existed only for the obsolescent attribute. If you want to take a
+> > stab at it, please feel free (but it just makes my head hurt :-).
+>
+> I think we could require the expression given in the Storage_Size
+> attribute definition clause to involve only constants and literals.
+> We say something similar about address clauses for objects, I believe.
+
+As previously noted, that is unique (I don't see anything like this for address clauses,
+not even in the recommended-level-of-support). Requiring the expression to be static
+would work (sort of), but would have some real-world incompatibilities.
+
+And that does absolutely nothing to eliminate the weirdness, indeed it makes it worse,
+because the aspect has no such limitations. (Remember that the weirdness is that that
+this attribute is not related to the aspect of the same name, at least in the sense
+that there is no "automatic" aspect for this attribute). The only thing that would
+fix that is eliminating the attribute altogether, which would be too incompatible
+to contemplate.
+
+So I honestly don't see the point; no user or implementer will be surprised by the
+semantics (at least after a bit of reflection - no one expects or wants
+attribute_definition_clauses to do per-object evaluation). And this is an *obsolescent*
+attribute; we really don't want to spend any effort on those at all.
+
+The only thing I would even consider changing is whether there ought to be an
+RM sentence in J.9 to make it crystal clear that the expression is evaluated here
+(and is not per-object). [There already is an AARM note to that effect.] Perhaps add
+something like:
+
+ Redundant[This specifies the Storage_Size aspect to have the value of the expression.]
+
+It would make the relationship between the attribute and aspect a bit clearer, too.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 10, 2011 9:32 PM
+
+>> I see no problem if we require that the attribute specification use
+>> only constants or literals. Then we equate it with the aspect
+>> specification, and we know it evaluates to the same value everywhere.
+>
+> I know of nothing like this anywhere else in the Ada standard. We have
+> rules that require static expressions, but that would prevent using
+> the storage size of some other task (T'Storage_Size) -- which would be
+> incompatible again. And creating a rule just for this case seems silly.
+
+This limitation is described in 13.1(22-22.h):
+
+22
+An implementation need not support representation items containing nonstatic
+expressions, except that an implementation should support a representation item
+for a given entity if each nonstatic expression in the representation item is
+a name that statically denotes a constant declared before the entity.
+
+22.a
+Reason: This is to avoid the following sort of thing:
+22.b
+X : Integer := F(...);
+Y : Address := G(...);
+for X'Address use Y;
+22.c
+In the above, we have to evaluate the initialization expression for X before we
+know where to put the result. This seems like an unreasonable implementation burden.
+22.d
+The above code should instead be written like this:
+22.e
+Y : constant Address := G(...);
+X : Integer := F(...);
+for X'Address use Y;
+22.f
+This allows the expression “Y” to be safely evaluated before X is created.
+22.g
+The constant could be a formal parameter of mode in.
+22.h
+An implementation can support other nonstatic expressions if it wants to. Expressions
+of type Address are hardly ever static, but their value might be known at compile time
+anyway in many cases.
+
+>>> The bizarre behavior seemed like the least evil of the options; it
+>>> doesn't break any existing code, and just requires that the
+>>> implementer treat the obsolescent attribute separately from the
+>>> aspect. That doesn't seem too hard to do.
+>>
+>> I don't agree with that. I think it is a mess as it is now.
+>> People will have a hard enough time with the new "aspect"
+>> concepts, and it will really help if, when thinking about attributes,
+>> they are interchangeable.
+>> If somehow specifying Storage_Size with an attribute definition
+>> clause is significantly different than specifying it with an aspect
+>> clause, the poor user will really be confused, and almost certainly
+>> implementors will mess it up one way or the other.
+>
+> But this is wrong: the attributes and aspects are subtly different,
+> and that has nothing to do with this attribute. The point at which the
+> expressions are resolved and evaluated differ for all aspect_specifications vs.
+> attribute_definition_clauses, and that can change the behavior even
+> for supposedly simple aspects like Size. We discussed that extensively
+> in the past.
+
+I guess I don't remember this issue as well as you do.
+
+> The same is true here. It *appears* to be more significant, but would
+> be only in pathological programs. After all, no per-object expressions
+> can appear in the attribute_definition_clause, and including function
+> calls or variables that change values when evaluated is just plain
+> weird. So, in practice, the result will be the same either way....
+
+I agree this is not worth making a big fuss over.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 10, 2011 9:52 PM
+
+> An implementation need not support representation items containing
+> nonstatic expressions, except that an implementation should support a
+> representation item for a given entity if each nonstatic expression in
+> the representation item is a name that statically denotes a constant declared
+> before the entity. ...
+
+For what it is worth, I know AdaMagic, and I believe GNAT, take advantage of
+13.1(22) and disallow non-static expressions in Address clauses that don't
+satisfy this requirement.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 10, 2011 10:21 PM
+
+OK, but two points:
+(1) That's Recommended Level of Support, so it's optional. What you were suggesting]
+ (if I understood it) was a requirement on all implementations -- and that's
+ different. It would need a more precise definition, and in any case we couldn't
+ use this one.
+(2) This already applies to the Storage_Size attribute; an implementation could
+ already make such a requirement if it wanted to. So there doesn't seem to be any
+ need for the language to do so.
+
+Bonus point: The above doesn't seem to allow the use of T'Size or T'Storage_Size in
+a representation item, even when the value of the attribute [aspect] was specified as
+a static expression. That's because the value of an attribute (aspect) isn't a
+"constant" (which has a formal definition - a constant has to be an object, and an
+attribute is not an object). That would be annoying; I suspect that in practice such
+things are allowed even if this permission is being used. (Janus/Ada has both the
+concepts of "static" and of "compile-time"; the former being a subset of the latter
+-- we use "compile-time" everywhere other than places where language rules require
+"static".)
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Saturday, October 1, 2011 5:54 PM
+
+C.3.1.
+6.3/3 reads:
+The value of aspect Attach_Handler is an expression, which shall be of type
+Interrupts.Interrupt_Id. This aspect is never inherited.
+
+The old version read:
+> For the Attach_Handler pragma, the expected type for the expression is
+> Interrupts.Interrupt_Id (see C.3.2).
+
+Comment 1: "the value is an expression" is not the usual way of expressing
+things, or it it? The value can only be the result of the expression.
+
+Comment 2:
+Why not simply:
+For the Attach_Handler aspect, the expected type for the expression is
+Interrupts.Interrupt_Id (see C.3.2).
+
+Comment 3: drop the ",". It is not a descriptive "which", but a restricting one,
+which is supposed to have no ",".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 10, 2011 8:17 PM
+
+I put the "Important" tag on this item because this wording is very common for
+aspects and if a change is necessary it is going to be very widespread in the
+Standard. For example, similar wording occurs for Storage_Size (13.3(65.2/3) and
+Priority (D.1(6.2/3)), along with many, many others.
+
+The statement has two purposes: (1) To specify that the value of the aspect is
+an expression (as opposed to a value). This is important, as it determines where
+the expression is evaluated (if a value, at the point of the freezing of the
+entity; if an expression, at some other point specifically defined). We want the
+"default" to be a value evaluated at the freezing point, so we don't need extra
+wording to deal with common cases like Size or Alignment or Pack. OTOH, we need
+the capability for later evaluation, for cases like preconditions and priority
+(per-object). The wording has to make it clear which is in fact used. 13.3.1(7/3
+and 19/3) show this bifurcation.
+
+(2) To define the type of the expression used in the aspect. This is required by
+13.3.1(7/3).
+
+So to answer your three comments:
+
+[1] No, this is not the usual way of putting this, because this is not the usual
+ case. The (value of the aspect) is an expression (as opposed to a value, as
+ for Size).
+
+[2] That would not say that the value of the aspect is an expression. (That is,
+ that this is an expression-valued aspect.)
+
+[3] These are two virtually unrelated statements sharing only "expression";
+ there has to be some separator.
+
+I note that Preconditions and Type_Invariants use a much, much wordier version
+of this text, mainly because we needed to define a name for the expression. And
+they use separate paragraphs for the type and for the "aspect is specified by an
+expression". I originally used longer wording in this spirit, and Bob Duff
+objected that the result was very wordy without saying much. I think he proposed
+some form of the simpler wording that we currently have.
+
+Anyway, the fact that I've already simplified this wording for Bob leaves me
+unsure what to do. The *correct* thing to do would be to write all of this
+wording similarly to Preconditions, which would result in something like:
+
+ Attach_Handler This aspect statically attaches an interrupt handler; it
+ shall be specified by an expression. This aspect is never
+ inherited.
+
+ Name Resolution Rules
+
+ For the Attach_Handler aspect, the expected type for the expression is
+ Interrupts.Interrupt_Id (see C.3.2).
+
+
+This is very wordy, and has the additional problem of needing to create a short
+description of the aspect to "flow" into the text; those would have to be
+reviewed by the group (I *will* make mistakes in doing more than a dozen such
+aspects). In addition, I don't think this wording really makes clear that it is
+the expression itself and not the value of the expression that is the value of
+the aspect. You can usually figure that out by reading *all* of the semantics
+(since they typically will describe where the expression is evaluated if it is
+an expression; if that's not mentioned, then it probably is a value), but that
+doesn't seem to be the best way to do it.
+
+So I don't know of any improvement here that makes sense. It should be noted
+that 13.3.1 does a lousy job of separating these two cases as well, so there may
+be a fairly deep-rooted problem here. (One of wording, not of intent.)
+Suggestions are welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, October 10, 2011 9:20 PM
+
+How about:
+
+ The aspect Attach_Handler is an expression of type Interrupts.Interrupt_Id.
+ This aspect is never inherited.
+
+I think it is confusing to use the term "value of aspect ... is an expression"
+and if we can avoid it, that would be a good thing. In 13.3.1 we simply say
+that an aspect *is* an expression or *is* a value.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, October 13, 2011 12:50 PM
+
+Let me suggest the following, which follows the words of 13.3.1 37/3 ("...unless
+the aspect itself is an expression") and 7/3 ("an aspect that is a value or an
+expression, the aspect_definition shall be an expression. The expected type for
+the expression is the type of the identified aspect of the associated entity;) :
+
+Turn the boilerplate that yields
+>The value of aspect Attach_Handler is an expression, which shall be of
+>type Interrupts.Interrupt_Id.
+
+Into:
+The aspect Attach_Handler is an expression, which shall be of type
+Interrupts.Interrupt_Id.
+
+and use the boilerplate wherever the aspect is indeed the expression that is to
+be evaluated at some later point, as in this case. (There are about 5 or 6 cases
+that fall into this category.)
+
+(Given the special semantics of "value = immediate evaluation, expression =
+delayed evaluation", that 13.3.1 introduces, it is terribly confusing to use
+both terms to explain a new aspect.)
+
+------
+
+Incidently, in 37/3, the second occurrence of expression (as cited above) is in
+the wrong font. It is not the syntactic notion of expression, but the semantic
+one, as in 7/3.
+
****************************************************************
Questions? Ask the ACAA Technical Agent