CVS difference for ais/ai-00251.txt

Differences between 1.18 and version 1.19
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2003/11/20 06:01:50	1.18
+++ ais/ai-00251.txt	2004/01/23 04:45:15	1.19
@@ -1,4 +1,4 @@
-!standard 03.04    (02)                            03-11-04  AI95-00251/10
+!standard 03.04    (02)                            04-01-22  AI95-00251/11
 !standard 03.09.01 (02)
 !class amendment 00-12-04
 !status work item 00-12-04
@@ -133,8 +133,8 @@
 Add after paragraph 35 (in the Notes section):
 
     18 An interface type which has an interface ancestor "is derived from"
-    that type, but it is not "a derived type". Conversely, a derived
-    type is never an interface type.
+    that type, and therefore is a derived type. A derived_type_definition,
+    however, never defines an interface type.
 
 3.4.1 Derivation Classes
 
@@ -145,9 +145,9 @@
 
 Replace the last sentence of paragraph 10 with:
 
-    The ultimate ancestor of a type is the ancestor of that type, if any, that
+    An *ultimate ancestor* of a type is an ancestor of that type that
     is not a descendant of any other type and that is not an interface
-    type (see 3.9.4).
+    type (see 3.9.4). Each untagged type has a unique ultimate ancestor.
 
 
 3.9.3 Abstract Types and Subprograms
@@ -173,11 +173,13 @@
 
         interface_type_definition ::= [LIMITED] INTERFACE [interface_list]
 
-                                 Legality Rules
+                                 Static Semantics
 
         An interface type (also called an "interface") is a specific abstract
         tagged type that is defined by an interface_type_definition.
 
+                                 Legality Rules
+
         An interface type shall have no components.
 
         All user-defined primitive subprograms of an interface type shall be
@@ -313,11 +315,12 @@
     the homograph and the mentioned library unit are both declared immediately
     within the same declarative region.
 
-    If two or more homographs are implicitly declared at the same place then
-    at most one shall be a non-null non-abstract subprogram. If all are null or
-    abstract, then all of the null subprograms shall be fully conformant with
-    one another. If all are abstract, then all of the subprograms shall be fully
-    conformant with one another.
+    If two or more homographs are implicitly declared at the same place (and
+    not overridden by a non-overridable declaration) then at most one shall be
+    a non-null non-abstract subprogram. If all are null or abstract, then all
+    of the null subprograms shall be fully conformant with one another. If all
+    are abstract, then all of the subprograms shall be fully conformant with
+    one another.
 
     All of these rules also apply to dispatching operations declared in the
     visible part of an instance of a generic unit. However, they do not apply
@@ -364,6 +367,8 @@
 
                                  Legality Rules
 
+        The actual type shall be an interface type.
+
         The actual type shall be a descendant of every ancestor of
         the formal type.
 
@@ -495,7 +500,7 @@
 
 ----
 
-Random notes:
+Technical notes:
 
 1) Inherited homographs must be overridden. If the homographs are
    not mode-conformant, then this may be impossible. Life's hard.
@@ -638,6 +643,10 @@
     example, this would mean that the operators inherited from P1.Ifc1
     would override those inherited from P2.Ifc2).
 
+9) The class of all interface types includes non-interface descendants
+   of interface types. This is the reason for the 12.5.5 legality rule
+   "The actual type shall be an interface type".
+
 !example
 
 An example involving interface types:
@@ -4107,5 +4116,272 @@
 
 [Editor's note: This wording is in version /10.]
 
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 10, 2004  12:50 PM
+
+The wording in AI-251 for 8.3(26/1, part 2) goes as follows:
+
+     If two or more homographs are implicitly
+     declared at the same place then
+     at most one shall be a non-null non-abstract
+     subprogram. If all are null or
+     abstract, then all of the null subprograms
+     shall be fully conformant with
+     one another. If all are abstract,
+     then all of the subprograms shall be fully
+     conformant with one another.
+
+I think we need to change this to:
+
+    ... declared at the same place {and not overridden
+    by a non-overridable declaration} then at most one...
+
+And it is important that this added condition is understood
+to apply to the whole paragraph (which might imply some further
+restructuring in the wording of the paragraph).
+
+I think it is important that you can inherit from interfaces
+with non-fully-conforming primitives, so long as you override
+the offending ones.
+
+On a separate topic, I remember we debated the definition
+of "ultimate ancestor type."  The latest AI-251 wording
+(2003-11-04, version 10, web-cvs rev 1.18) has ultimate
+ancestor not including any interface types.  Is that
+still what we want?  It seems to violate the general desire
+to allow an existing "normal" abstract type to be converted to
+an interface type without significant change to existing
+semantics.
+
+Perhaps we checked the RM and found it didn't matter, but
+I will admit it still makes me a bit uncomfortable.
+
+****************************************************************
+
+From: Stephen W. Baird
+Sent: Saturday, January 10, 2004  1:58 PM
+
+Tuck says:
+...
+> I think we need to change this to:
+
+>     ... declared at the same place {and not overridden
+>     by a non-overridable declaration} then at most one...
+
+Good point. I agree.
+
+> And it is important that this added condition is understood
+> to apply to the whole paragraph (which might imply some further
+> restructuring in the wording of the paragraph).
+
+I think your wording is fine as is.
+
+> I think it is important that you can inherit from interfaces
+> with non-fully-conforming primitives, so long as you override
+> the offending ones.
+
+Right.
+
+> On a separate topic, I remember we debated the definition
+> of "ultimate ancestor type."  The latest AI-251 wording
+> (2003-11-04, version 10, web-cvs rev 1.18) has ultimate
+> ancestor not including any interface types.  Is that
+> still what we want?
+
+I think that we do not want a type to have more than one ultimate ancestor.
+If you want to allow interface types as ultimate ancestors, that is the problem
+you have to deal with.
+
+> It seems to violate the general desire
+> to allow an existing "normal" abstract type to be converted to
+> an interface type without significant change to existing
+> semantics.
+
+Could you be more specific?
+
+> Perhaps we checked the RM and found it didn't matter, but
+> will admit it still makes me a bit uncomfortable.
+
+The (soon to be distributed) version of AI-251 that I'm currently working on
+includes the following definition of "ultimate ancestor":
+
+    3.4.1 Derivation Classes
+
+    ...
+
+    Replace the last sentence of paragraph 10 with:
+
+        An *ultimate ancestor* of a type is an ancestor of that type that
+        is not a descendant of any other type and that is not an interface
+        type (see 3.9.4). Each untagged type has a unique ultimate ancestor.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 10, 2004  10:44 PM
+
+We could define the ultimate ancestor by following the "parent"
+relationship, where the parent is the first type
+named in the derived type or interface type definition, whether
+or not it is an interface type.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Sunday, January 11, 2004  9:03 AM
+
+I think the notion of "ultimate ancestor" is used only for access and
+array types.  So why should we care if tagged types can have just one,
+or more than one, or if the concept is even defined for them?
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, January 12, 2004  4:38 AM
+
+Tuck proposed:
+
+> We could define the ultimate ancestor by following the
+> "parent" relationship, where the parent is the first type
+> named in the derived type or interface type definition, whether
+> or not it is an interface type.
+
+I would hate to give the impression that the first type named in the
+derivation is special (that's in the case where it is an interface; of
+course it is special when it is a normal tagged type).  I realize that
+your proposed definition would not really make the first type different
+from all the others, but it would be confusing.
+
+Bob commented:
+
+> I think the notion of "ultimate ancestor" is used only for
+> access and array types.  So why should we care if tagged
+> types can have just one, or more than one, or if the concept
+> is even defined for them?
+
+Assuming that this is true (and Bob is infallible in matters of Ada
+doctrine) then the sensible thing to do is to define ultimate ancestor
+only for untagged types.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 12, 2004  3:41 PM
+
+Pascal replied to Bob:
+>
+> > I think the notion of "ultimate ancestor" is used only for
+> > access and array types.  So why should we care if tagged
+> > types can have just one, or more than one, or if the concept
+> > is even defined for them?
+>
+> Assuming that this is true (and Bob is infallible in matters of Ada
+> doctrine) then the sensible thing to do is to define ultimate ancestor
+> only for untagged types.
+
+"Ultimate ancestor" is used in 3.4.1(10) [definition]; 7.6.1(11) [access];
+4.5.3(6-7) [array]; 3.10.2 [access]; 4.3.2(4.a) [tagged, but not normative -
+it's describing what was NOT done in defining the language]; and 9.3(2)
+[access].
+
+Still, I'd prefer to define it as Steve's latest description: interfaces are
+ignored for this purpose. One can consider the "ultimate ancestor" as the
+first type that can have data components and concrete primitive operations.
+
+Tucker's worry:
+"It seems to violate the general desire to allow an existing "normal"
+abstract type to be converted to an interface type without significant
+change to existing semantics."
+isn't significant here, because (1) the definition of ultimate ancestor
+doesn't affect the semantics of an abstract type; and (2) it isn't going to
+be possible to change to an interface very often anyway. Certainly, every
+abstract type I've ever used has had some concrete routines - they provide a
+convinient place to put shared operations which will rarely, if ever, need
+to be overridden. That's especially true if you prefer to keep your
+derivation trees shallow (branching directly above the root). Therefore,
+most of the time, you'll need to add another level to use an interface --
+direct conversion is impossible.
+
+The reason to keep the semantics similar for all tagged types (including
+interfaces) is just to make them easier to use and understand for Ada users.
+But if there are necessary differences, we shouldn't get overly concerned
+about them.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 12, 2004  3:34 PM
+
+The alternative we discussed was to define the ultimate ancestor(s)
+of a type.  We could then claim that for an untagged record
+or array type, there is exactly one, for what that's worth.
+
+It just seems odd to talk about the "ultimate ancestor"
+being a type that clearly has ancestors.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 13, 2004  3:07 PM
+
+Bob said:
+> I think the notion of "ultimate ancestor" is used only for
+> access and array types.  So why should we care if tagged
+> types can have just one, or more than one, or if the concept
+> is even defined for them?
+
+On that line, here's what my meeting notes say about this topic (I didn't
+remember discussing it, I just found these as I was processing the minutes...)
+
+"Ultimate ancestor" is used rarely, and only access types seem to care (and
+they can't have multiple ancestors.) So we should allow multiple ultimate
+ancestors; add a note saying that "the ultimate ancestor" is well-defined for
+untagged types. 3.4.1(10) would change "The ancestor" to  "An ancestor". Then
+add "For an untagged type, there is only one ultimate ancestor, and it is
+designated as *the ultimate ancestor* of the type."
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, January 13, 2004  4:02 PM
+
+> Then add "For an untagged type, there is only one ultimate ancestor, and it
+> is designated as *the ultimate ancestor* of the type."
+
+Do we really need the ", and it is designated..." part?  I mean, doesn't
+that follow from the normal rules of English?
+
+Just trying to cut down on useless verbiage...
+
+****************************************************************
+
+From: Stephen W. Baird
+Sent: Wednesday, January 14, 2004  6:07 PM
+
+This version of AI-251 reflects the discussion of the San Diego meeting.
+
+Changes include:
+  1)  An interface type which has an interface ancestor (e.g. "type T is
+      interface Some_Other_Interface_Type") is a derived type. Formerly it was
+      defined to not be a derived type and Erhard asked why. The only reason I
+      could come up with was that it seemed odd to declare a derived type
+      without using the keyword "new". This did not seem to justify introducing
+      the confusing notion of a type which "is derived from" another type but
+      which is not "a derived type".
+
+  2)  Changes to the definition of "ultimate ancestor" which have already been
+      discussed in recent ARG mail messages.
+
+  3)  Tuck's recently suggested change to the overriding rules.
+
+  4)  Some minor presentation changes:
+         a definition which was formerly in a "legality rules" section
+	    was moved into a "static semantics" section
+         "Random notes" => "Technical notes";
+         the addition of technical note #9 .
+
+[Editor's note: This is version /11.]
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent