CVS difference for ai05s/ai05-0267-1.txt
--- ai05s/ai05-0267-1.txt 2011/11/09 03:21:25 1.3
+++ ai05s/ai05-0267-1.txt 2011/12/22 07:22:07 1.4
@@ -1,5 +1,14 @@
-!standard 13.3.1(0) 11-11-01 AI05-0267-1/01
+!standard 13.3.1(0) 11-12-21 AI05-0267-1/02
+!standard 7.2(2)
+!standard 9.1(6)
+!standard 9.4(7)
+!standard 10.1.3(3/2)
+!standard 10.1.3(4)
+!standard 10.1.3(5)
+!standard 10.1.3(6)
!class Amendment 11-11-01
+!status Amendment 2012 11-12-21
+!status ARG Approved 8-0-1 11-11-12
!status work item 11-11-01
!status received 11-10-26
!priority Low
@@ -23,64 +32,214 @@
such items. We probably should adopt the same rules/syntax for stubs as we do
subprogram bodies. Specifically, we should allow aspect_specifications on a
stub IFF there is no subprogram specification (and in that case, they are
-not allowed on the body).
+not allowed on the body).
+Add aspect_specifications to stubs? (Yes.)
+
(3) Some (yet-to-be-defined) aspects may make sense on bodies (even if there
is a specification). For subprograms, the syntax is already there, so there is
no problem. But for other program units, we are only allowing aspects on the
specification. It was suggested to allow the syntax on bodies, and also
add a bit of wording to essentially say that no language-defined aspects are
-allowed there. We already have a precident for that, as there aren't any
+allowed there. We already have a precedent for that, as there aren't any
aspects allowed on generic formal types (but we do allow the syntax for
future use).
-(4) There was some discussion of body preconditions and postconditions.
-The former can easily be modeled with an assert pragma, but the later cannot
-because of the 'Old and 'Result attributes and the possibility of multiple
-exits. We don't want to call these things "postconditions" as that is a
-contract thing and we want to keep contracts separate from other proof
-aids. It was suggested to allow aspects Assert_on_Entry and Assert_on_Exit
-on subprogram bodies, and allow the 'Old and 'Result attributes in the latter.
+Add aspect_specification to bodies? (Yes.)
!wording
-** TBD.
+Replace 7.2(2):
+
+package_body ::=
+ package body defining_program_unit_name
+ [aspect_specification] is
+ declarative_part
+ [begin
+ handled_sequence_of_statements]
+ end [[parent_unit_name.]identifier];
+
+Replace 9.1(6):
+
+task_body ::=
+ task body defining_identifier
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [task_identifier];
+
+Replace 9.4(7):
+
+protected_body ::=
+ protected body defining_identifier
+ [aspect_specification] is
+ { protected_operation_item }
+ end [protected_identifier];
+
+Replace 10.1.3(3/2):
+
+subprogram_body_stub ::=
+ [overriding_indicator]
+ subprogram_specification is separate
+ [aspect_specification];
+
+Replace 10.1.3(4):
+
+package_body_stub ::=
+ package body defining_identifier is separate
+ [aspect_specification];
+
+Replace 10.1.3(5):
+
+task_body_stub ::=
+ task body defining_identifier is separate
+ [aspect_specification];
+
+Replace 10.1.3(6):
+protected_body_stub ::=
+ protected body defining_identifier is separate
+ [aspect_specification];
+
+Add after 13.3.1(16/3):
+
+There are no language-defined aspects that may be specified on a renaming_declaration,
+a generic_formal_parameter_declaration, a subunit, a package_body, a task_body,
+a protected_body, or a body_stub other than a subprogram_body_stub.
+
+A language-defined aspect shall not be specified in an aspect_specification given on
+a subprogram_body or subprogram_body_stub that is a completion.
+
+Delete 13.3.1(34-35/3) [moved above].
+
!discussion
(1) For this, a principle was given that aspect_specifications go at the
-end of declarations, other than program units and bodies (where they go before
-"is".
+end of declarations, other than program units (that are not subprogram specifications)
+and bodies (where they go before "is".
This principle should be added to the AARM as a "Language Design Principle",
so that future Ada designers can figure out what the heck we were thinking.
-
-John suggested:
- The appropriate layout should be obvious. In the case of a structure that has
- a specification and body, the aspect specification goes with the specification
- before is. The only case where a body can have an aspect specification is a
- subprogram without a separate specification in which case the aspect goes
- before the is of the body. But when something is all in one piece such as a
- null procedure, object declaration or generic instantiation any aspect
+ Syntactically, aspect_specifications generally are located at the end of
+ declarations. When a declaration is all in one piece such as a null procedure,
+ object declaration, or generic instantiation the aspect
specification goes at the end of the declaration; it is then more visible and
less likely to interfere with the layout of the rest of the structure.
+ However, we make an exception for program units (other than subprogram
+ specifications) and bodies, in which the aspect_specification goes before
+ the is. In these cases, the entity could be large and could contain other
+ declarations that also have aspect_specifications, so it is better to put
+ the aspect_specification toward the top of the declaration. (Some aspects - such
+ as Pure - also affect the legality of the contents of a unit, so it would be
+ annoying to only see those after reading the entire unit.)
-[I think we can do better than this, and surely we should drop the first
-sentence from an AARM note. But it's a good start - Editor.]
-
(2) This seems important for consistency.
+
+(3) This seems like a good idea for future flexibility.
+
+!corrigendum 7.2(2)
-(3) This seems like a good idea for future flexibility. [But it will require
-enough wording changes that it might be too late - Editor.]
+@drepl
+@xcode<@fa<package_body ::=
+ >@b<@ft<package body>>@fa< defining_program_unit_name >@b<@ft<is>>@fa<
+ declarative_part
+ [>@b<@ft<begin>>@fa<
+ handled_sequence_of_statements]
+ >@b<@ft<end>>@fa< [[parent_unit_name.]identifier]>>
+@dby
+@xcode<@fa<package_body ::=
+ >@b<@ft<package body>>@fa< defining_program_unit_name
+ [aspect_specification] >@b<@ft<is>>@fa<
+ declarative_part
+ [>@b<@ft<begin>>@fa<
+ handled_sequence_of_statements]
+ >@b<@ft<end>>@fa< [[parent_unit_name.]identifier]>>
+
+!corrigendum 9.1(6)
+
+@drepl
+@xcode<@fa<task_body ::=
+ >@b<@ft<task body>>@fa< defining_identifier [>@b<@ft<is>>@fa<
+ declarative_part
+ >@b<@ft<begin>>@fa<
+ handled_sequence_of_statements
+ >@b<@ft<end>>@fa< [>@b<@ft<task_>>@fa<identifier];>>
+@dby
+@xcode<@fa<task_body ::=
+ >@b<@ft<task body>>@fa< defining_identifier
+ [aspect_specification] [>@b<@ft<is>>@fa<
+ declarative_part
+ >@b<@ft<begin>>@fa<
+ handled_sequence_of_statements
+ >@b<@ft<end>>@fa< [>@b<@ft<task_>>@fa<identifier];>>
+
+!corrigendum 9.4(7)
+
+@drepl
+@xcode<@fa<protected_body ::=
+ >@b<@ft<protected body>>@fa< defining_identifier >@b<@ft<is>>@fa<
+ { protected_operation_item }
+ >@b<@ft<end>>@fa< [>@b<@ft<protected_>>@fa<identifier];>>
+@dby
+@xcode<@fa<protected_body ::=
+ >@b<@ft<protected body>>@fa< defining_identifier
+ [aspect_specification] >@b<@ft<is>>@fa<
+ { protected_operation_item }
+ >@b<@ft<end>>@fa< [>@b<@ft<protected_>>@fa<identifier];>>
+
+!corrigendum 10.1.3(3/2)
+
+@drepl
+@xcode<@fa<subprogram_body_stub ::=
+ [overriding_indicator]
+ subprogram_specification >@ft<@b<is separate>>@fa<;>>
+@dby
+@xcode<@fa<subprogram_body_stub ::=
+ [overriding_indicator]
+ subprogram_specification >@ft<@b<is separate>>@fa<
+ [aspect_specification];>>
+
+!corrigendum 10.1.3(4)
+
+@drepl
+@xcode<@fa<package_body_stub ::= >@ft<@b<package body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<;>>
+@dby
+@xcode<@fa<package_body_stub ::=
+ >@ft<@b<package body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<
+ [aspect_specification];>>
+
+!corrigendum 10.1.3(5)
+
+@drepl
+@xcode<@fa<task_body_stub ::= >@ft<@b<task body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<;>>
+@dby
+@xcode<@fa<task_body_stub ::=
+ >@ft<@b<task body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<
+ [aspect_specification];>>
+
+!corrigendum 10.1.3(6)
+
+@drepl
+@xcode<@fa<protected_body_stub ::= >@ft<@b<protected body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<;>>
+@dby
+@xcode<@fa<protected_body_stub ::=
+ >@ft<@b<protected body>>@fa< defining_identifier >@ft<@b<is separate>>@fa<
+ [aspect_specification];>>
-(4) This is a good idea. But it seems to be too late for Ada 2012; there is
-no way to consider the semantic ramifications or edit the wording. [Best
-to make an Ada 2012 AI?? - Editor]
+!corrigendum 13.3.1(0)
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
+
!ACATS test
-** TBD.
+Since there aren't any language-defined aspects allowed in these contexts, there
+is no way to test that aspects are allowed. (One could check the content of the
+error messages, but that is not allowed by ACATS testing rules.) So no tests are
+needed.
!ASIS
@@ -1869,7 +2028,9 @@
From: Erhard Ploedereder
Sent: Friday October 28, 2011 12:21 PM
-Ok, before someone complains, I forgot separately compiled bodies without spec. But the advice: "you want aspects, you compile it separately" is too bad to even mention ;-)
+Ok, before someone complains, I forgot separately compiled bodies without spec.
+But the advice: "you want aspects, you compile it separately" is too bad to even
+mention ;-)
****************************************************************
Questions? Ask the ACAA Technical Agent