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. ;-)
 
 ****************************************************************