CVS difference for ai12s/ai12-0056-1.txt
--- ai12s/ai12-0056-1.txt 2013/05/01 23:54:28 1.3
+++ ai12s/ai12-0056-1.txt 2013/06/08 04:58:44 1.4
@@ -1,9 +1,10 @@
-!standard 1.1(3/3) 13-05-01 AI05-0056-1/03
+!standard 1.1(3/3) 13-06-07 AI05-0056-1/04
!standard 1.1.2(24/3)
!standard 3.9(12.4/3)
!standard 3.10(22/2)
!standard 5.2(20)
!standard 6.1(39)
+!standard 6.2(13)
!standard A.18.25(10/3)
!standard A.18.26(9.2/3)
!class presentation 12-12-12
@@ -41,6 +42,9 @@
8) Formal procedure Swap in A.18.26(9.2/3) should have an explicit mode "in"
for its parameters.
+9) Add two user notes in 6.2 to point at where the rules about parameter modes
+really are.
+
!question
1) The Next_Frame example in 6.1(39) uses type Frame, which is labeled "see 3.10".
@@ -71,6 +75,10 @@
but our style is to always give an explicit mode on procedure parameters. Should
there be an explicit mode "in" here? (Yes.)
+9) 6.2 is titled "Formal parameter modes". But nothing in this clause is about
+parameter modes other than the introduction 6.2(1) and the note 6.2(13). Should
+we do more? (Yes.)
+
!recommendation
(See Summary.)
@@ -117,6 +125,17 @@
with procedure Swap (Left, Right : {in} Index_Type);
+9) Add new notes on either side of 6.2(13):
+
+ {The mode of a formal parameter describes the direction of information transfer
+ to or from the subprogram_body (see 6.1).}
+
+ A formal parameter of mode *in* is a constant view (see 3.3); it cannot be
+ updated within the subprogram_body.
+
+ {A formal parameter of mode *out* may be partially or completely uninitialized
+ at the start of the subprogram_body (see 6.4.1).}
+
!discussion
1) The intent is that the examples in the Standard, taken as a whole, are
@@ -192,7 +211,16 @@
7) This is pretty clearly a cut-and-paste error, as a similar bullet appears
in each of the bounded container sections.
-8)
+8) Our standard style has modes on all procedure parameters, so this one should
+as well.
+
+9) This clause got its name from Ada 83, when it really did define the formal
+parameter modes. But the normative rules all of moved away. In order for the
+Standard to live up to its name ("Ada Reference Manual"), we at least should
+have some references to the actual normative rules. Since a note already
+provides one such reference, we add two more notes to give the other two
+for the other most important rules.
+
!corrigendum 1.1(3/3)
@drepl
@@ -270,6 +298,22 @@
@b<function> Find(B : @b<aliased in out> Barrel; Key : String) @b<return> Real;
--@ft<@i< see 4.1.5>>>
+!corrigendum 6.2(13)
+@drepl
+@xindent<@s9<NOTES@hr
+6 A formal parameter of mode @b<in> is a constant view (see 3.3); it cannot be updated
+within the @fa<subprogram_body>.>>
+@dby
+@xindent<@s9<NOTES@hr
+6 The mode of a formal parameter describes the direction of information transfer
+to or from the @fa<subprogram_body> (see 6.1).>>
+
+@xindent<@s9<7 A formal parameter of mode @b<in> is a constant view (see 3.3); it cannot be updated
+within the @fa<subprogram_body>.>>
+
+@xindent<@s9<8 A formal parameter of mode @b<out> may be partially or completely uninitialized
+at the start of the @fa<subprogram_body> (see 6.4.1).>>
+
!corrigendum A.18.25(10/3)
@drepl
@xcode< @b<function> Copy (Source : Tree; Capacity : Count_Type := 0)
@@ -497,5 +541,77 @@
Sent: Wednesday, May 1, 2013 8:07 PM
In A.18.26(9.2/3), the procedure Swap really ought to have mode in on its parameters.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 22, 2013 3:52 PM
+
+Steve Baird pointed out as an "observation" that 6.2, Formal Parameter Modes,
+doesn't actually contain any rules about formal parameter modes; the only
+mention of modes is in the non-normative introductory text and in a note.
+
+The actual definitions and important rules for formal parameter modes are in
+6.1(18) [the definition]; 3.3(17) [in mode is a constant]; and 6.4.1(12-15)
+[out parameters might not be initialized].
+
+Since we usually call this document the Ada REFERENCE Manual, one would hope
+that it could be used for - ahem - reference. As such, a section called
+"formal parameter modes" ought to at least mention the important rules about
+formal parameter modes and provide cross-references, even if it isn't an
+appropriate place anymore for the actual rules.
+
+[Aside: This name comes from the Ada 83 standard, where it actually defined
+the meaning of these modes. That got moved to 6.1 in Ada 9x, but the name of
+the clause remained unchanged.]
+
+We could of course change the name of the clause (to something like "parameter
+passing mechanisms"), but then the introduction and note don't really fit.
+
+A better approach is to add notes cross-referencing the other important rules
+for "formal parameter modes". Something like (the second note is the one that
+already exists):
+
+Notes
+
+{The mode of a formal parameter describes the direction of information transfer
+to or from the subprogram_body (see 6.1).}
+
+A formal parameter of mode *in* is a constant view (see 3.3); it cannot be
+updated within the subprogram_body.
+
+{A formal parameter of mode *out* may be partially or completely uninitialized
+at the start of the subprogram_body (see 6.4.1).}
+
+---
+
+As notes are non-normative, we can add them as part of the presentation AI (thus,
+no separate AI is needed).
+
+Obviously, this proposed change does not meet the Duff rule of relevance, so I
+have to presume Bob is against it. Is that a general opinion or should I stick
+this into the presentation AI??
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, February 22, 2013 4:04 PM
+
+> Obviously, this proposed change does not meet the Duff rule of
+> relevance, so I have to presume Bob is against it.
+
+You know me well.
+
+I'm even against answering emails about it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 22, 2013 4:20 PM
+
+Which you just did. :-) This seems like an Onion headline: "Bob Duff opposes
+own actions!" :-) :-)
+
+P.S. Sorry, it's Friday. ;-)
****************************************************************
Questions? Ask the ACAA Technical Agent