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

--- ai05s/ai05-0110-1.txt	2011/03/19 05:18:09	1.11
+++ ai05s/ai05-0110-1.txt	2011/04/15 05:37:32	1.12
@@ -1,4 +1,6 @@
-!standard 12.5(20/2)                                            11-03-18  AI05-0110-1/03
+!standard 3.4(7)                                  11-04-14  AI05-0110-1/04
+!standard 7.3(16/2)
+!standard 12.5.1(20/2)
 !standard 12.5.1(21/3)
 !class binding interpretation 08-08-08
 !status work item 08-08-08
@@ -81,7 +83,7 @@
      by its ancestor type and its progenitor types (if any), in the
      same way that those of a record extension are determined
      by those of its parent type and its progenitor
-     types (see 3.4).
+     types (see 3.4 and 7.3.1).
 
    Replace 12.5.1(20/2)
 
@@ -98,9 +100,9 @@
      is a new discriminant_part specified), predefined operators,
      and inherited user-defined primitive subprograms are determined
      by its ancestor type and its progenitor types (if any), in the
-     same way that those of a record extension are determined
+     same way that those of a derived type are determined
      by those of its parent type and its progenitor
-     types (see 3.4).
+     types (see 3.4 and 7.3.1).
 
    Replace the beginning of 12.5.1 (21/3)
 
@@ -121,7 +123,7 @@
 
 The model of inheritance for characteristics of a type is described in 3.4 and
 7.3.1. Ada 95 did not use this model for formal derived types, rather repeating
-the wording in 12.5 and 12.5.1. (This appears be have occurred because the
+the wording in 12.5 and 12.5.1. (This appears to have occurred because the
 formal definition of "characteristics" was added late during the development
 of Ada 9x.) This wording repeat never seems to be quite correct, we are
 continually finding examples such as the one in the question.
@@ -848,10 +850,10 @@
 From: Randy Brukardt
 Date: Friday, March 4, 2011  10:19 PM
 
-> I wonder whether predefined operators should be part of the 
-> characteristics, while the other primitive subprograms are not.  
-> Predefined operators "wink" into existence whenever we learn more 
-> about a type, whereas non-predefined primitive subprograms only get 
+> I wonder whether predefined operators should be part of the
+> characteristics, while the other primitive subprograms are not.
+> Predefined operators "wink" into existence whenever we learn more
+> about a type, whereas non-predefined primitive subprograms only get
 > implicitly declared at a smaller number of places.
 
 I suspect that we'll have trouble either way. :-)
@@ -912,5 +914,77 @@
       same way that those of a record extension are determined
       by those of its parent type and its progenitor
       types (see 3.4).
+
+****************************************************************
+
+From: John Barnes
+Date: Thursday, April  7, 2011  7:02 AM
+
+Looks reasonable.
+
+!discussion
+
+Minor typo in third line   "be have ocurred"
+
+
+All for now Will resume after plumber.
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Tuesday, April 12, 2011  4:02 PM
+
+One of my homework items from the last phone meeting was to decide if we should
+add a reference to 7.3.1 in paragraph 12.5.1(20/2) as well as possibly in
+7.3(16/2), as revised by AI05-0110.
+
+My conclusion is that in both cases it would be helpful to add the reference.
+In each of those paragraphs, the parenthetical reference at the end, which says
+"(see 3.4)", would be changed to "(see 3.4 and 7.3.1)".  Although there's a
+forward reference from 3.4 to 7.3.1 in the description of inherited operations
+that that can be declared later, there doesn't seem to be a similar reference
+for other characteristics, such as components.  In any case, I think that adding
+the references to 7.3.1 in these paragraphs would be helpful to some readers.
+Obviously not a big deal if the refs are left as is, but that's my
+recommendation.
+
+----
+
+While looking at the above, I noticed a more substantive wording issue in
+12.5.1(20/2), as revised by AI05-0110, that I'd like addressed.  This paragraph
+is talking about determination of characteristics and operations of formal
+derived types:
+
+  For a formal derived type, the characteristics (including components,
+  but excluding discriminants if there is a new discriminant_part specified),
+  predefined operators, and inherited user-defined primitive subprograms are
+  determined by its ancestor type and its progenitor types (if any), in the
+  same way that those of a record extension are determined by those of its
+  parent type and its progenitor types (see 3.4).
+
+The issue is about the last part of the revised sentence, where it says "in the
+same way that those of a record extension are determined by those of its parent
+type and progenitor types (see 3.4)."  Since we're talking about formal derived
+types (and not specifically formal private extensions) in this paragraph, I
+believe it would be more natural to say "derived type" rather than "record
+extension" in this paragraph.
+
+When Steve was originally crafting the wording here, he did say "derived type",
+but as a result of the following request from Tucker at the Feb, 2011 St. Pete
+meeting (quoting from the minutes here):
+
+ Tucker would like to make the wording parallel to 7.3(16) [private extensions].
+
+he revised the wording to follow 7.3(16), which draws a parallel between private
+extensions and record extensions.  However, the more accurate parallel in the
+case of 12.5.1(20/2) is to say "derived type", since the paragraph is talking
+about formal derived types generally.  While the proposed wording may not be
+wrong, I think "derived type" is more appropriate here.  (Note also that
+3.4(23/2) talks in terms of derived types, not record extensions, when
+discussing visibility and inheritance of subprograms inherited from parents and
+progenitors.)
+
+I discussed this with both Steve and Tuck, and they agreed that this change
+would be reasonable.
 
 ****************************************************************