CVS difference for ai05s/ai05-0004-1.txt
--- ai05s/ai05-0004-1.txt 2008/01/17 07:24:41 1.13
+++ ai05s/ai05-0004-1.txt 2008/03/07 06:15:18 1.14
@@ -1,4 +1,4 @@
-!standard C.7.1(17/2) 08-01-16 AI05-0004-1/10
+!standard C.7.1(17/2) 08-02-21 AI05-0004-1/11
!standard 1.1.2(21)
!standard 1.1.4(14.1/2)
!standard 3.8(11)
@@ -11,8 +11,6 @@
!standard 4.3.3(32)
!standard 7.3(10.1/2)
!standard 7.4(10)
-!standard 7.6(16)
-!standard 7.6(18)
!standard 10.1.3(10)
!standard 10.1.1(17)
!standard 12.3(7)
@@ -23,12 +21,13 @@
!standard D.9(6)
!standard J.1
!class presentation 06-03-15
+!status ARG Approved 9-0-0 08-02-08
!status work item 06-05-12
!status received 06-03-15
!priority Low
!difficulty Easy
!qualifier Omission
-!subject Presentation issues in the Standard.
+!subject Presentation issues in the Standard
!summary
@@ -74,13 +73,10 @@
19) The mode of Person in Remove_First in 3.9.4(29/2) should be "out" not "in".
-20) Assignment operations are now defined for limited types, so 7.6(16) and 7.6(18)
-should not have parenthetical references to "nonlimited".
-
-21) The title of Annex M has changed, so the reference to it in 1.1.2(21) should be to
+20) The title of Annex M has changed, so the reference to it in 1.1.2(21) should be to
"Summary of Documentation Requirements".
-22) Mod should be included in the list of attribute designators.
+21) Mod should be included in the list of attribute designators.
!question
@@ -96,7 +92,7 @@
was parenthesized expression meant instead? (Yes.)
5) 4.1(7) uses the syntax font for attributes, but the syntax for attributes is called
-a attribute_reference. Change this? (Yes.)
+an attribute_reference. Change this? (Yes.)
6) 7.3(10.1/2) says "is a derived_type_definition", but there is no such thing.
@@ -135,8 +131,8 @@
the Department of Redundancy Department? (Yes.)
14) 3.9.4(20/2) defines a dispatching operation Cur_Count (among others). However,
-the comment in paragraph 22/2 refers (twice) to "Count". Shouldn't this
-should be "Cur_Count"? (Yes.)
+the comment in paragraph 22/2 refers (twice) to "Count". Shouldn't this be
+"Cur_Count"? (Yes.)
15) A.18.7(58/2) is defining the meaning of Intersection, so why does the text
refer to Union? (It should say Intersection.)
@@ -156,16 +152,12 @@
19) The mode of Person in Remove_First in 3.9.4(29/2) does not match that of the
interface that it is derived from. Is that correct? (No.)
-
-20) The assignment operation is defined for all types in the Amendment. But 7.6(16)
-and 7.6(18) have parenthetical remarks suggesting that they apply only to nonlimited
-types. Should that be corrected? (Yes.)
-21) 1.1.2(21) refers to Annex M as "Implementation-Defined Characteristics", but the
+20) 1.1.2(21) refers to Annex M as "Implementation-Defined Characteristics", but the
Amendment changed the name to "Summary of Documentation Requirements". Should this be
corrected? (Yes.)
-22) 4.1.4(3) gives a list of attribute designators, explicitly allowing those attribute
+21) 4.1.4(3) gives a list of attribute designators, explicitly allowing those attribute
names which are reserved words. The Amendment added the Mod attribute, whose name is
a reserved word, but it was not added to this syntax. Should this be done? (Yes.)
@@ -191,7 +183,7 @@
7) D.9(6) should say select_alternative.
-8) 12.3(7) should say generic_assocation.
+8) 12.3(7) should say generic_association.
9) 10.1.3(10) should say task declaration and protected declaration.
@@ -213,24 +205,30 @@
18) 7.4(10) should say "subtype_indication{, access_definition,} or".
+Add an AARM ramification:
+For non-imported constants, these elaborations cannot require any code or checks
+for a legal program, because the given subtype_indication has to be indefinite
+or statically match that of the full constant, meaning that either it is a
+subtype_mark or it has static constraints. If the deferred constant instead has
+an access_definition, the designated subtype must be a subtype_mark.
+We still say that these are elaborated, however, because part of elaboration
+is creating the type, which is clearly needed for access_definitions.
+(A deferred constant and its full constant have different types when
+they are specified by an access_definition, although there is no
+visible effect of these types being different as neither can be named.)
+
19) 3.9.4(29/2) should be changed as follows:
"procedure Remove_First (Q : in out Fast_Food_Queue; Person : {out}[in] Person_Name);"
-20) The first sentence of 7.6(16) should be modified:
- To adjust the value of a [(nonlimited)] composite object, the values of the components
- of the object are first adjusted in an arbitrary order, and then, if the object is
- {nonlimited} controlled, Adjust is called.
-"nonlimited" should be deleted from 7.6(18).
+20) 1.1.2(21) should say Annex M, "Summary of Documentation Requirements".
-21) 1.1.2(21) should say Annex M, "Summary of Documentation Requirements".
+21) 4.1.4(3) should include "Mod".
-22) 4.1.4(3) should include "Mod".
-
!discussion
1) entry_barrier is syntactically within entry_body. C.7.1(17/2) however, says
-"entry body", which is not defined by the Standard. The most reasomable assumption
+"entry body", which is not defined by the Standard. The most reasonable assumption
is that "entry_body" was meant, especially as the intent is that barriers may be
evaluated by any task. We therefore avoid confusion by changing the wording to use
the syntax term.
@@ -242,7 +240,7 @@
don't have discriminants anyway. [Editor's note: This correction was made in the Ada
Europe RM edition; see below for why.]
-4) There isn't a definition of the term "parenthisized expression", either, even though
+4) There isn't a definition of the term "parenthesized expression", either, even though
we use it all over the place. [Editor's note: This correction was made in the Ada
Europe RM edition; see below for why.]
@@ -289,7 +287,7 @@
15) This is an obvious cut-and-paste error.
-16) This is an objvious placement error. Note that this error is only in the RM, and
+16) This is an obvious placement error. Note that this error is only in the RM, and
not in the Amendment.
17) This appears to be a change missed during the corrigendum work. It would be
@@ -303,20 +301,12 @@
19) The mode needs to match that of the primitive subprogram of the interface that we're
deriving from.
-
-20) These two paragraphs apply to all types, and surely should not claim to not apply
-to nonlimited types only. The implementation permission of 7.6(17.1/2) depends on 7.6(21/2),
-a rule which is under the header of 7.6(18): we better include limited types in 7.6(18).
-
-In addition, 7.6(16) should say that Adjust is called only for nonlimited controlled types,
-so that the canonical semantics (before the build-in-place requirement of 7.6(17.1/2)
-is applied) is well-defined.
-21) The Ada Europe version (both on-line and printed), incorrectly references clause M.2 in
+20) The Ada Europe version (both on-line and printed), incorrectly references clause M.2 in
this paragraph, because the old Annex title was used for that clause (and the tools thus
used it for the cross-reference). Obviously, we want to use the correct title.
-22) This is a clear oversight. Surely it is intended to be able to write the 'Mod attribute,
+21) This is a clear oversight. Surely it is intended to be able to write the 'Mod attribute,
which the standard carefully defines.
!corrigendum 1.1.2(12)
@@ -464,30 +454,6 @@
@fa<access_definition>, or (only allowed in the case of an imported constant)
the @fa<array_type_definition>.
-!corrigendum 7.6(16)
-
-@drepl
-To adjust the value of a (nonlimited) composite object, the values of the components
-of the object are first adjusted in an arbitrary order, and then, if the object
-is controlled, Adjust is called. Adjusting the value of an elementary
-object has no effect, nor does adjusting the value of a composite object with no
-controlled parts.
-@dby
-To adjust the value of a composite object, the values of the components
-of the object are first adjusted in an arbitrary order, and then, if the object
-is nonlimited controlled, Adjust is called. Adjusting the value of an elementary
-object has no effect, nor does adjusting the value of a composite object with no
-controlled parts.
-
-!corrigendum 7.6(18)
-
-@drepl
-An implementation is allowed to relax the above rules (for nonlimited controlled
-types) in the following ways:
-@dby
-An implementation is allowed to relax the above rules (for controlled types) in
-the following ways:
-
!corrigendum 10.1.1(17)
@drepl
@@ -892,54 +858,6 @@
Sent: Wednesday, August 1, 2007 1:26 AM
Correction: Remove_First is wrong, not Append
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Friday, August 24, 2007 10:38 PM
-
-Not wanting to do anything tough, I'm working on test objectives for 7.6 this evening
-before leaving. I noticed a very minor glitch in 7.6(16) and 7.6(18).
-
-7.6(13-15) talks about the canonical implementation of the assignment operation. That
-is now defined for limited types. 7.6(16) defines adjustment for, including a call to
-Adjust. The paragraph parenthetically claims to apply only to non-limited types, but that
-begs the question of what the meaning of this is for limited types. (Yes, I know that
-later requirements are intended to make this moot, but should the canonical semantics
-really be undefined??)
-
-So I suggest removing the parenthetical non-limited, and adding a word to make it clear
-that adjusting a limited type is a no-op (and surely does not call a routine that does
-not exist!):
-
-"To adjust the value of a [(nonlimited)] composite object, the values of the components
-of the object are first adjusted in an arbitrary order, and then, if the object is
-{nonlimited} controlled, Adjust is called. Adjusting the value of an elementary object
-has no effect, nor does adjusting the value of a composite object with no controlled parts."
-
-We could add something to the last phrase about limited objects, but since it is already
-considered redundant, it isn't necessary (and might be considered conflicting with the
-requirements following).
-
-The AARM note at 7.6(16.a) also needs a bit of repair.
-
-There is a similar problem with 7.6(18). It has a parenthetical "for nonlimited
-controlled types", but 7.6(21/2) is the rule that 7.6(17.1/2) is requiring to be
-implemented -- for both limited and nonlimited aggregates (and functions for that
-matter). It's quite clear that 7.6(21/2) *can* happen for limited types, the
-so-called proof of 7.6(18.a) notwithstanding.
-
-So I propose dropping "nonlimited" from 7.6(18) and fixing 7.6(18.a) to read
-something like:
- Ramification: The rules below about assignment_statements apply only to
- nonlimited controlled types, as assignment_statements are not allowed for
- limited types. The other rule applies to both limited and nonlimited types,
- and in fact is required for all assignment operations involving aggregates
- and function calls. This is important because the programmer can count on
- a stricter semantics for limited controlled types.
-
-As both of these are parenthetical remarks, they don't affect the correctness of
-the language. As such, I propose to add these changes to the presentation AI.
****************************************************************
Questions? Ask the ACAA Technical Agent