CVS difference for ais/ai-00401.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00401.txt

--- ais/ai-00401.txt	2005/11/16 06:51:17	1.8
+++ ais/ai-00401.txt	2005/12/15 02:44:17	1.9
@@ -1,4 +1,4 @@
-!standard 3.4(01)                                      05-11-15  AI95-00401/06
+!standard 3.4(01)                                      05-11-30  AI95-00401/07
 !standard 3.4(03)
 !standard 3.4(05)
 !standard 3.4(08)
@@ -192,15 +192,14 @@
 body comes from the corresponding primitive subprogram of the parent type of
 the full view. See 3.9.2.
 
-Similarly, if the ancestor type is an interface type, the parent type can be
-anything so long as the full view is a descendant of the ancestor type.
+If the ancestor type specified in a private_extension_declaration is an
+interface type, the parent type can be anything so long as the full view is a
+descendant of the ancestor type. The progenitor types specified in a
+private_extension_declaration and the progenitor types specified in the
+corresponding declaration of a record extension given in the private part also
+need not be the same -- the only requirement is that the private extension and
+the record extension be descended from the same set of interfaces.
 
-The progenitor types specified in a private_extension_declaration and the
-progenitor types specified in the corresponding declaration of a record
-extension given in the private part need not be the same -- the only
-requirement is that the private extension must be descended from each interface
-from which the record extension is descended.
-
 
 Delete the first paragraph added after 9.1(9.1) by AI95-00345.
 
@@ -465,16 +464,14 @@
 while the body comes from the corresponding primitive subprogram of the parent
 type of the full view. See 3.9.2.>>
 
-@xindent<@s9<  Similarly, if the ancestor type is an interface type, the parent
-type can be anything so long as the full view is a descendant of the ancestor
-type.>>
-
-@xindent<@s9<8  The progenitor types specified in a
-@fa<private_extension_declaration> and the progenitor types specified in the
-corresponding declaration of a record extension given in the private part need
-not be the same @emdash the only requirement is that the private extension must
-be descended from each interface from which the record extension is
-descended.>>
+@xindent<@s9<8  If the ancestor type specified in a
+@fa<private_extension_declaration> is an interface type, the parent type can be
+anything so long as the full view is a descendant of the ancestor type. The
+progenitor types specified in a @fa<private_extension_declaration> and the
+progenitor types specified in the corresponding declaration of a record
+extension given in the private part need not be the same @emdash the only
+requirement is that the private extension and
+the record extension be descended from the same set of interfaces.>>
 
 !corrigendum 9.1(9.1/1)
 
@@ -2057,6 +2054,300 @@
 as the operations are well-defined and don't potentially conflict with
 normal practice. I usually use the queuing example as a strawman, since it
 is a much better fit for interfaces.
+
+****************************************************************
+
+From: Duncan Sands
+Sent: Thursday, November 17, 2005  10:09 AM
+
+We have started using interfaces in our code, using the recent GNAT
+implementation, and immediately ran into an annoyance:
+
+Suppose I want to declare a tagged private type Tagged_Type and specify
+that it implements some interface Interface_Type.  It seems I have to do
+as follows:
+
+package Example is
+...
+   type Tagged_Type is new Interface_Type with private;
+...
+private
+...
+   type Tagged_Type is new Interface_Type with...
+...
+end;
+
+i.e. I am required to derive Tagged_Type from Interface_Type.  Contrast
+this with the following (invented syntax):
+
+package Example2 is
+...
+   type Tagged_Type is tagged private and Interface_Type;
+...
+private
+...
+   type Tagged_Type is new Some_Other_Tagged_Type and Interface_Type with...
+...
+end;
+
+In Example2 the intent is simply to state that Tagged_Type implements
+the interface, but is not necessarily derived from it.  There seems to
+be no way to do this currently.  I came across this while building up
+families of successively more complicated types, analogous to the packages
+below.  I've commented out the declarations I would really like to
+make, but which aren't provided for in the current draft.  Is there any
+reason to forbid this kind of construction?
+
+Full example:
+
+package Simple_Interface is
+
+   type Simple_Interface_Type is interface;
+
+   procedure Do_Something_Simple (SI : Simple_Interface_Type) is abstract;
+
+end;
+
+with Simple_Interface;
+package Complex_Interface is
+
+   type Complex_Interface_Type is
+     interface and Simple_Interface.Simple_Interface_Type;
+
+   procedure Do_Something_More_Complicated (
+     SI : Complex_Interface_Type
+   ) is abstract;
+
+end;
+
+with Simple_Interface;
+package Simple_Example is
+
+   type Simple_Type is new Simple_Interface.Simple_Interface_Type with private;
+   -- forced to derive from Simple_Interface_Type, even though we only want to
+   -- say that we implement it
+
+--   type Simple_Type
+--     is tagged private and Simple_Interface.Simple_Interface_Type;
+
+   procedure Do_Something_Simple (ST : Simple_Type);
+
+private
+   type Simple_Type
+     is new Simple_Interface.Simple_Interface_Type with null record;
+--   type Simple_Type is Simple_Interface.Simple_Interface_Type with null record;
+end;
+
+with Complex_Interface;
+private with Simple_Example;
+package Complex_Example is
+
+   type Complex_Type
+     is new Complex_Interface.Complex_Interface_Type with private;
+   -- forced to derive from Complex_Interface_Type, even though we only want to
+   -- say that we implement it
+
+--   type Complex_Type
+--     is tagged private and Complex_Interface.Complex_Interface_Type;
+
+   procedure Do_Something_Simple (CT : Complex_Type);
+   procedure Do_Something_More_Complicated (CT : Complex_Type);
+
+private
+   type Complex_Type is new Simple_Example.Simple_Type
+     and Complex_Interface.Complex_Interface_Type with null record;
+   -- illegal, but would be fine with the alternative declarations
+end;
+
+****************************************************************
+
+From: Duncan Sands
+Sent: Monday, November 21, 2005  1:26 PM
+
+> In Example2 the intent is simply to state that Tagged_Type implements
+> the interface, but is not necessarily derived from it.
+
+By this, as I hope was clear, I mean that Tagged_Type has the interface
+as progenitor or parent, as opposed to having the interface as parent,
+which is what seems to be the only choice right now.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 21, 2005  1:51 PM
+
+...
+> Suppose I want to declare a tagged private type Tagged_Type and specify
+> that it implements some interface Interface_Type.  It seems I have to do
+> as follows:
+>
+> package Example is
+> ...
+>    type Tagged_Type is new Interface_Type with private;
+> ...
+> private
+> ...
+>    type Tagged_Type is new Interface_Type with...
+> ...
+> end;
+>
+> i.e. I am required to derive Tagged_Type from Interface_Type.
+
+No, that's wrong. The Note 7.3(20) only applies to non-interface types
+(we're rewording it to fix that).
+
+...
+> In Example2 the intent is simply to state that Tagged_Type implements
+> the interface, but is not necessarily derived from it.
+
+You're confused (possibly by the broken note). Tagged_Type is "derived from"
+every interface ancestor of the type, not just the progenitors and parent.
+(3.4.1(2) defines both "derived directly from" and "derived indirectly
+from".)
+
+"implements an interface" is not a technical term in Ada 2005.
+
+> There seems to be no way to do this currently.
+
+Yes, there is. The following is legal:
+
+package Example3 is
+...
+   type Tagged_Type is new Interface_Type with private;
+...
+private
+...
+   type Tagged_Type is new Some_Other_Tagged_Type and Interface_Type with...
+...
+end;
+
+The rule in question only requires that both types are descended from the
+same set of interfaces.
+
+> I came across this while building up
+> families of successively more complicated types, analogous to the packages
+> below.  I've commented out the declarations I would really like to
+> make, but which aren't provided for in the current draft.  Is there any
+> reason to forbid this kind of construction?
+
+No, because it isn't forbidden. (Of course, the implementation you are using
+may have bugs...)
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Monday, November 21, 2005  1:53 PM
+
+> No, because it isn't forbidden. (Of course, the implementation you
+> are using may have bugs...)
+
+What??? Unheard of....  In fact Pascal and Tucker straightened us out
+on this point, and this is being fixed as we speak.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Monday, November 21, 2005  1:55 PM
+
+...
+> In Example2 the intent is simply to state that Tagged_Type implements
+> the interface, but is not necessarily derived from it.
+
+[clarified in a later message:]
+
+>> By this, as I hope was clear,
+
+It wasn't.
+
+> There seems to
+> be no way to do this currently.  I came across this while building up
+> families of successively more complicated types, analogous to the packages
+> below.  I've commented out the declarations I would really like to
+> make, but which aren't provided for in the current draft.  Is there any
+> reason to forbid this kind of construction?
+
+
+I don't see anything in 7.3 that prohibits this:
+
+    package Example is
+        type Tagged_Type is new Interface_Type with private;
+    private
+        type Tagged_Type is new Some_Other_Tagged_Type
+                            and Interface_Type with......
+    end Example;
+
+
+I also don't see why it would make a difference that Interface_Type is
+a parent instead of a progenitor.  The syntax defines it as such;
+however, I'm not aware of any substantial difference this makes.  If
+you have a type derived from interface types:
+
+    type T1 is I1 and I2 and I3 and I4 with record ... end record;
+
+Assuming I1-I4 are all interface types, the language calls I1 the
+"parent" type and I2, I3, and I4 "progenitors".  However, I'm not
+aware of any real difference---that is, I don't think there's any
+property of I1 as it pertains to this type that isn't also a property
+of I2, I3, or I4.
+
+I could have missed something on either of these points, and I'm sure
+someone more knowledgeable than I will point it out.
+
+****************************************************************
+
+From: Duncan Sands
+Sent: Monday, November 21, 2005  2:53 PM
+
+Hi Randy, thanks for replying.
+
+...
+> You're confused (possibly by the broken note). Tagged_Type is "derived from"
+> every interface ancestor of the type, not just the progenitors and parent.
+> (3.4.1(2) defines both "derived directly from" and "derived indirectly
+> from".) "implements an interface" is not a technical term in Ada 2005.
+
+Sorry for the terminological sloppiness - I fired off the email in the heat of
+the moment.
+
+...
+> No, because it isn't forbidden. (Of course, the implementation you are using
+> may have bugs...)
+
+That is great news, this is indeed what I was looking for.  Unfortunately, the
+implementation I am using rejects the above Example3.  Calling this a bug seems
+a bit mean though, if the version of 7.3(20) that allows Example3 hasn't been
+written yet...  I will send in a bug report none-the-less!
+
+****************************************************************
+
+From: Duncan Sands
+Sent: Monday, November 21, 2005  3:06 PM
+
+Hi Adam,
+
+> >> By this, as I hope was clear,
+>
+> It wasn't.
+
+sorry about that: type in haste, repent at leasure.
+
+> I don't see anything in 7.3 that prohibits this:
+>
+>     package Example is
+>         type Tagged_Type is new Interface_Type with private;
+>     private
+>         type Tagged_Type is new Some_Other_Tagged_Type
+>                             and Interface_Type with......
+>     end Example;
+
+Well, it seems to be forbidden by the version of 7.3(20) at
+http://www.adaic.com/standards/rm-amend/html/RM-7-3.html, since
+"the parent type of the full view can be any descendant of the ancestor type"
+seems to be trying to say that the parent type of the full view must be
+a descendant of the ancestor type, which is not the case in the above Example.
+
+However Randy Brukardt pointed out in his reply that this is not what
+was intended.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent