CVS difference for ai05s/ai05-0269-1.txt

--- ai05s/ai05-0269-1.txt	2012/04/03 22:21:06	1.11
+++ ai05s/ai05-0269-1.txt	2012/04/21 04:39:19	1.12
@@ -654,7 +654,7 @@
 bit, but not enough to justify the complication of introducing seven additional paragraphs.
 
 For (44), the question was raised why the parameters in this package aren't lined up
-as in most language defined packages. That was not done here as it was not done in 
+as in most language defined packages. That was not done here as it was not done in
 the parent System.Storage_Pools package, and it seemed important to be consistent with
 that package. Changing System.Storage_Pools to align the parameters seems wrong as it
 is not modified by Ada 2012.
@@ -2573,7 +2573,7 @@
 
 > No doubt Randy will want wording.
 
-Well, actually, I was going to write it myself (ye how asks and all of that),
+Well, actually, I was going to write it myself (ye who asks and all of that),
 but thanks for doing it anyway.
 
 > I suggest adding after RM-3.2.4(12/3):
@@ -2637,6 +2637,50 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Saturday, January 28, 2012 12:04 AM
+
+> Following is my dispositions on the comments submitted by an ARG
+> member (in this case, Tucker Taft).
+> ...
+>> A.18.10(5/3)
+>>       The nodes of a subtree can be visited in several different orders.
+>>       For a depth-first {pre-}order, [the last step of] {after} visiting a
+>>       node{,} [is to visit] the nodes of its child list [in] {are each
+>>       visited in depth-first, pre-}order, recursively.
+>
+> Humm. If we add "pre-" into this term, we'd have to change all of the
+> uses as well (which you didn't suggest). There are 8 such uses. And I
+> don't think this "pre-order" makes much sense in normal use: we're
+> defining an order here.
+
+The problem is that "depth-first" doesn't really say anything about whether
+children are visited before or after the node itself.  Here we seem to be
+describing a "pre-order" in that the node is visited, and then its children.
+But I can live with this ambiguity.  If anything, if someone said "depth-first"
+and didn't say "pre-order" to me, I would assume that the node itself is visited
+last.  But again, probably not that big a deal, as we define it here for our own
+use.
+
+> ...
+>        The nodes of a subtree can be visited in several different orders.
+>        For a depth-first order, [the last step of] {after} visiting a
+>        node{,} [is to visit] the nodes of its child list {are each
+>        visited in depth-first order}, each child node visited in
+> natural order
+>        (first child to last child)[order, recursively].
+>
+> But of course "natural order" isn't defined well. I considered using
+> "child order" instead, but that actually seems like it should be a term.
+>
+> I used this text for now, pending improvements from you.
+
+I would recommend we revert to the original wording.
+If we aren't going to try to insert the term "pre-order,"
+then I think it is probably best left as it was.
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Saturday, February  4, 2012 12:35 AM
 
@@ -2648,14 +2692,15 @@
 
 Erhard points out (in a very convoluted way, unfortunately, I wasted 20 minutes
 writing an explanation before stumbling onto his point), that this means that
-implicitly declared subprograms, like inherited primitives, aren't covered by invariant
-checks "on the way back". And this means that 7.3.2(22/3) is a lie, which is surely
-not our intent.
-
-I can't find any reason for the "explicitly" in this bullet, so I've just deleted it,
-in which case the rules work and the note is true. But I worry that it was there for
-some good reason. If the reason was to avoid wrappers, well, we decided that we didn't
-want to do that (as evidenced by the 7.3.2(22/3) note), so then the word is just wrong.
+implicitly declared subprograms, like inherited primitives, aren't covered by
+invariant checks "on the way back". And this means that 7.3.2(22/3) is a lie,
+which is surely not our intent.
+
+I can't find any reason for the "explicitly" in this bullet, so I've just
+deleted it, in which case the rules work and the note is true. But I worry that
+it was there for some good reason. If the reason was to avoid wrappers, well, we
+decided that we didn't want to do that (as evidenced by the 7.3.2(22/3) note),
+so then the word is just wrong.
 
 If there was any other reason, I can't figure it out, and I didn't find anything in the
 AIs to help. Anyone else remember? (Tucker in particular.) More generally, anyone know