CVS difference for ais/ai-00251.txt

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

--- ais/ai-00251.txt	2002/06/14 23:48:56	1.8
+++ ais/ai-00251.txt	2002/10/01 03:08:54	1.9
@@ -1,4 +1,4 @@
-!standard 03.04    (02)                            02-06-13  AI95-00251/05
+!standard 03.04    (02)                            02-09-27  AI95-00251/06
 !standard 03.09.01 (02)
 !class amendment 00-12-04
 !status work item 00-12-04
@@ -9,12 +9,11 @@
 
 !summary
 
-This proposal adds "abstract interface" types ("interface" for short) to the
-standard. A tagged type may "implement" one or more such interfaces. The
-classwide type associated with the interface "covers" all types that implement
-it. Dispatching calls through the primitives of the abstract interface type
-dispatch to code bodies associated with specific tagged types that implement
-the interface.
+This proposal adds "interface" types to the standard. A tagged type may
+"implement" one or more such interfaces. The classwide type associated with the
+interface "covers" all types that implement it. Dispatching calls through the
+primitives of the interface type dispatch to code bodies associated with
+specific tagged types that implement the interface.
 
 !problem
 
@@ -434,87 +433,65 @@
 to match this wording.]
 
 In 3.1 add
-
     basic_declaration ::= ... | null_procedure_declaration
 
 
 In 3.2.1 add
+    type_definition ::= ... | interface_type_definition
 
-        type_definition ::= ... | abstract_interface_definition
-
-Replace 3.4(2)
-
-    derived_type_definition ::=
-        [ABSTRACT] NEW parent_subtype_indication
-        [record_extension_part]
-with
-    derived_type_definition ::=
-        [ABSTRACT] NEW parent_subtype_indication
-        [[AND abstract_interface_list] record_extension_part]
 
-Add after 3.4(23):
-    A type which implements an abstract interface (see 3.9.x) inherits
+Add after 3.4(23)
+    A type that implements an interface type (see 3.9.4) inherits
     subprograms from the interface type, in the same way as for a type
     derived from the interface type.
 
-Add between sentences 3 and 4 of 3.9(3):
-     The accessibilty level (see 3.10.2) of a type which implements an
-     abstract interface (see 3.9.4) shall not be statically deeper than
-     that of the interface type.
 
-Add after the first sentence 3.4.1(9):
-    If a type T1 implements an abstract interface type T2 (see 3.9.x),
+Add after the first sentence of 3.4.1(9):
+    If a type T1 implements an interface type T2 (see 3.9.4),
     then T2'Class also covers all types covered by T1'Class.
 
-Add after sentence 1 of 3.9(4):
-     An abstract interface shall not be
-     implemented in a generic body if the interface type is declared
-     outside that body.
+In 3.9.1(2), replace
+    record_extension_part ::= WITH record_definition
+with
+    record_extension_part ::= WITH [interface_list AND] record_definition
+
+In 3.9.1(3), add between sentences 3 and 4:
+    The accessibilty level (see 3.10.2) of a type that implements an
+    interface type (see 3.9.4) shall not be statically deeper than
+    that of the interface type.
+
+In 3.9.1(4), add after sentence 1:
+    An interface type shall not be implemented in a generic body if the
+    interface type is declared outside that body.
 
 Add after 3.9.3(6):
-     Corresponding rules apply for a type which inherits an abstract
-     subprogram by implementing an abstract interface (see 3.9.x, 3.4).
+    Corresponding rules apply for a type that inherits an abstract
+    subprogram by implementing an interface type (see 3.9.4, 3.4).
 
 Add a new subclause after 3.9.3:
-Abstract Interface Types
-
-    An abstract interface type is an abstract tagged type intended for use
+3.9.4  Interface Types
+    An interface type is an abstract tagged type intended for use
     in providing a restricted form of multiple inheritance.
     A tagged type may "implement" multiple interfaces, thereby allowing
     multiple views of objects of the type.
 
                              Syntax
+    interface_type_definition ::= [LIMITED] INTERFACE [WITH interface_list]
+    interface_list ::= interface_subtype_mark {AND interface_subtype_mark}
 
-    abstract_interface_definition ::= ABSTRACT [LIMITED] INTERFACE
+    An interface type (also called an "interface") is a specific abstract
+    tagged type that is defined by an interface_type_definition.
+    [An interface type has no components.]
 
-    abstract_interface_list ::=
-        abstract_interface_subtype_mark
-        {AND abstract_interface_subtype_mark}
-
                              Legality Rules
 
-    An abstract interface type (also called an "interface type" or
-    "interface") is a specific abstract tagged type that is defined by an
-    abstract_interface_definition, or by a derived_type_definition or
-    formal_derived_type_definition where the keyword ABSTRACT
-    appears and the parent type is an interface type.
-
-    An interface type shall have no components.
-
     All primitive operations of an interface type shall be abstract
     subprograms or null procedures.
-
-    The type of a subtype named in an abstract_interface_list shall be an
-        interface type.
 
-    A descendant of a type which names an interface type in an
-    abstract_interface_list, or which is derived from an interface type, is
-    said to "implement" the interface and any other interfaces implemented by
-    that interface. A class-wide type implements the interfaces implemented by
-    the corresponding specific type. The corresponding full view of a partial
-    view of a type implements all interfaces implemented by the partial view.
+    The type of a subtype named in an interface_list shall be an
+    interface type.
 
-    A type which implements an interface shall be limited if and only
+    A type that implements an interface shall be limited if and only
     if the interface type is limited.
 
     If a partial view defines an interface type, then the corresponding
@@ -530,6 +507,30 @@
     (see 12.3), these rules apply also in the private part of an instance
     of a generic unit.
 
+                             Static Semantics
+
+    A descendant of a type that names an interface type in an
+    interface_list, or that is derived from an interface type,
+    is said to "implement" the interface and any other interfaces
+    implemented by that interface.
+    A class-wide type implements the interfaces implemented by the
+    corresponding specific type. The corresponding full view of a
+    partial view of a type implements all interfaces implemented by
+    the partial view.
+
+In 4.5.2(13), replace:
+    Two access-to-subprogram values are unequal if they designate different
+    subprograms. [It is unspecified whether two access
+    values that designate the same subprogram but are the result of distinct
+    evaluations of Access attribute_references are equal or unequal.]
+with
+    Two access-to-subprogram values are unequal if they designate different
+    non-null subprograms. [It is unspecified whether two access
+    values that designate the same subprogram but are the result of distinct
+    evaluations of Access attribute_references are equal or unequal. It is
+    also unspecified whether two access values that designate different null
+    subprograms are equal or unequal.]
+
 Replace 4.6(21-23) with:
 
   If the target type is tagged, then either:
@@ -542,7 +543,6 @@
   there shall be a type that is an ancestor of both the target type and the
   operand type.
 
-
 In 6.1 replace
    subprogram_specification ::= PROCEDURE defining_program_unit_name
                                           parameter_profile
@@ -569,61 +569,72 @@
     This execution has no effect.
 
 In 7.3, replace
-
-    private_extension_declaration ::=
-      type defining_identifier [discriminant_part] is
-      [ABSTRACT] NEW ancestor_subtype_indication WITH PRIVATE;
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication WITH PRIVATE;
 with
-    private_extension_declaration ::=
-      type defining_identifier [discriminant_part] is
-      [ABSTRACT] NEW ancestor_subtype_indication
-      [[AND abstract_interface_list] WITH PRIVATE];
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication
+          WITH [interface_list AND] PRIVATE;
 
 Add after paragraph 8.3(12):
 
-    An implicit declaration of a subprogram which is neither abstract nor
-    a null procedure overrides that of a subprogram simultaneously
-    inherited by implementing an abstract interface.
-
-    If one subprogram overrides another and a type simultaneously inherits
-    subprograms corresponding to both, then the inherited subprogram
-    corresponding to the overriding subprogram overrides the other
-    inherited subprogram.
+    An implicit declaration of an inherited subprogram which is neither
+    abstract nor a null procedure overrides that of a subprogram
+    inherited by implementing an interface that is implicitly
+    declared at the same place.
+
+    If one subprogram overrides another and a type inherits subprograms
+    corresponding to both that are implicitly declared at the same place,
+    then the inherited subprogram corresponding to the overriding
+    subprogram overrides the other inherited subprogram.
 
     If an inherited subprogram corresponds to another subprogram and a
-    type simultaneously inherits subprograms corresponding to both, then
-    the subprogram corresponding to the inherited subprogram overrides the
-    other inherited subprogram.
-
-Add after paragraph 8.3(23):
-
-    If two non-overridden homographs are simultaneously inherited as
-    primitive operations of a tagged type which implements an abstract
-    interface, then they shall be fully conformant and either both shall
-    be abstract subprograms or both shall be null procedures.
+    type inherits subprograms corresponding to both that are implicitly
+    declared at the same place, then the subprogram corresponding to the
+    inherited subprogram overrides the other inherited subprogram.
+
+    If a type that implements an interface inherits two or more
+    fully conformant abstract subprograms, or two or more fully
+    conformant null subprograms, that are implicitly declared
+    at the same place, and if the preceding rules would not specify
+    any overriding relationships among these subprograms, then
+    the implementation shall select one of these subprograms and it
+    shall override the others.
 
-In 12.5.1, replace
+In 12.5, add
+    formal_type_declaration ::= ... | formal_interface_type_definition
 
+In 12.5.1, replace
     formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
                                        [WITH PRIVATE]
 with
     formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
-                                       [[AND abstract_interface_list]
-                                       WITH PRIVATE]
-
-Add after 12.5.1(18);
-
-    If the formal type is an abstract interface type, then the actual type
-    shall be an abstract interface type.
+                                       [WITH [interface_list AND] PRIVATE]
 
+Add after 12.5.1(18):
     The actual type shall implement any interfaces that are implemented by
     the formal type.
 
-Add after paragraph 13.14(7):
+Add a new subclause after 12.5.4:
+12.5.5 Formal Interface Types
 
-    The implementation of an abstract interface causes freezing of the
-    abstract interface type.
+   The class determined for a formal interface type is the class of all
+   interface types.
+
+                                 Syntax
+        formal_interface_type_definition ::= interface_type_definition
+
+                                 Legality Rules
+   The actual type shall implement any interfaces that are implemented by
+   the formal type.
 
+   The actual type shall be limited if and only if the formal type is limited.
+
+Add after 13.14(7):
+   The implementation of an interface causes freezing of the interface type.
+
 !ACATS test
 
 !appendix
@@ -1698,6 +1709,573 @@
 
 
 Comments?
+
+****************************************************************
+
+From: Steve Baird
+Sent: Wednesday, September 25, 2002   1:12 PM
+
+This is my attempt at incorporating the comments of the Vienna meeting
+into AI-251.
+Changes include:
+   1) "abstract interface" => "interface" in both terminology and syntax.
+   2) A derived type is never an interface type, as described in the
+      Vienna meeting minutes. To get the effect of derivation, declare
+      a second interface type which implements the first one.
+   3) The notion of implicit declarations being declared "simultaneously"
+      is replaced with declarations occurring implicitly "at the same point".
+   4) Formal interface types are added.
+   5) A different way of expressing the notion that if a routine inherits
+      two null homographs or two abstract homographs, then there is
+      really no ambiguity.
+   6) Expand the definition of "cover" so that Some_Interface_Type'Class
+      covers all types which implement the interface.
+   7) Define the "implements" relation to be transitive.
+
+I'm not at all sure that these are all improvements, but I believe/hope that
+they reflect the consensus of the group.
+See also the discussion points at the end.
+
+  -- Steve
+
+----------------
+
+
+Interface Types
+    3.2.1
+
+    Add
+        type_definition ::= ... | interface_type_definition
+    --------
+    3.4
+
+    Add after paragraph 23:
+        A type which implements an interface type (see 3.9.4) inherits
+        subprograms from the interface type, in the same way as for a type
+        derived from the interface type.
+    --------
+    3.4.1(9)
+
+    Add after the first sentence:
+        If a type T1 implements an interface type T2 (see 3.9.4),
+        then T2'Class also covers all types covered by T1'Class.
+
+    --------
+
+    3.9.1
+
+    In paragraph 2, replace
+        record_extension_part ::= WITH record_definition
+    with
+        record_extension_part ::= WITH [interface_list AND] record_definition
+    .
+
+    Add between sentences 3 and 4 of paragraph 3:
+         The accessibilty level (see 3.10.2) of a type which implements an
+         interface type (see 3.9.4) shall not be statically deeper than
+         that of the interface type.
+
+    Add after sentence 1 of paragraph 4:
+         An interface type shall not be
+         implemented in a generic body if the interface type is declared
+         outside that body.
+    --------
+
+    3.9.3
+
+     Add after paragraph 6:
+
+         Corresponding rules apply for a type which inherits an abstract
+         subprogram by implementing an interface type (see 3.9.4, 3.4).
+
+    --------
+    3.9.4 Interface Types
+        An interface type is an abstract tagged type intended for use
+        in providing a restricted form of multiple inheritance.
+        A tagged type may "implement" multiple interfaces, thereby allowing
+        multiple views of objects of the type.
+                                 Syntax
+        interface_type_definition ::= [LIMITED] INTERFACE [WITH interface_list]
+        interface_list ::= interface_subtype_mark {AND interface_subtype_mark}
+                                 Legality Rules
+        An interface type (also called an "interface") is a specific abstract
+        tagged type that is defined by an interface_type_definition.
+
+        An interface type shall have no components.
+
+        All primitive operations of an interface type shall be abstract
+        subprograms or null procedures.
+
+        The type of a subtype named in an interface_list shall be an
+        interface type.
+
+        A descendant of a type which names an interface type in an
+        interface_list, or which is derived from an interface type,
+        is said to "implement" the interface and any other interfaces
+        implemented by that interface.
+        A class-wide type implements the interfaces implemented by the
+        corresponding specific type. The corresponding full view of a
+        partial view of a type implements all interfaces implemented by
+        the partial view.
+
+        A type which implements an interface shall be limited if and only
+        if the interface type is limited.
+
+        If a partial view defines an interface type, then the corresponding
+        full view shall define an interface type.
+
+        If a full view implements an interface, then the corresponding
+        partial view (if any) shall implement the interface.
+
+        For an interface type declared in a visible part, a primitive
+        subprogram shall not be declared in the private part.
+
+        In addition to the places where Legality Rules normally apply
+        (see 12.3), these rules apply also in the private part of an instance
+        of a generic unit.
+
+   --------
+
+    4.6
+
+    Replace paragraphs 21-23 with:
+
+      If the target type is tagged, then either:
+        The operand type shall be covered by or descended from the target type; or
+        The operand type shall be a class-wide type that covers the target type.
+
+      If the target type is not included in any of the above five cases,
+      there shall be a type that is an ancestor of both the target type and the
+      operand type.
+
+    --------
+
+    7.3
+
+    Replace
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication WITH PRIVATE;
+    with
+        private_extension_declaration ::=
+          type defining_identifier [discriminant_part] is
+          [ABSTRACT] NEW ancestor_subtype_indication
+          WITH [interface_list AND] PRIVATE;
+
+    --------
+    8.3
+
+    Add after paragraph 12:
+        An implicit declaration of an inherited subprogram which is neither
+        abstract nor a null procedure overrides that of a subprogram
+        inherited by implementing an interface which is implicitly
+        declared at the same point.
+
+        If one subprogram overrides another and a type inherits subprograms
+        corresponding to both which are implicitly declared at the same point,
+        then the inherited subprogram corresponding to the overriding
+        subprogram overrides the other inherited subprogram.
+
+        If an inherited subprogram corresponds to another subprogram and a
+        type inherits subprograms corresponding to both which are implicitly
+        declared at the same point, then the subprogram corresponding to the
+        inherited subprogram overrides the other inherited subprogram.
+
+        If a type which implements an interface inherits two or more
+        fully conformant abstract subprograms, or two or more fully
+        conformant null subprograms, which are implicitly declared
+        at the same point, and if the preceding rules would not specify
+        any overriding relationships among these subprograms, then
+        the implementation shall select one of these subprograms and it
+        shall override the others.
+
+    --------
+
+    12.5
+
+    Add
+        formal_type_declaration ::= ... | formal_interface_type_definition
+    --------
+
+    12.5.1
+
+    Replace
+        formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                           [WITH PRIVATE]
+    with
+        formal_derived_type_definition ::= [ABSTRACT] NEW subtype_mark
+                                           [WITH [interface_list AND] PRIVATE]
+
+
+    Add after paragraph 18:
+
+        The actual type shall implement any interfaces that are implemented by
+        the formal type.
+
+    --------
+    12.5.5 Formal Interface Types
+
+    The class determined for a formal interface type is the class of all
+    interface types.
+
+
+                                 Syntax
+        formal_interface_type_definition ::= interface_type_definition
+
+                                 Legality Rules
+    The actual type shall implement any interfaces that are implemented by
+    the formal type.
+    The actual type shall be limited if and only if the formal type is limited.
+
+    --------
+
+    13.14
+
+    Add after paragraph 7:
+
+        The implementation of an interface causes freezing of the
+        interface type.
+
+    --------
+
+Discussion:
+   1) A derived type is never an interface type. One can derive from an
+      interface type, but the result is not an interface. Instead, define
+      a new interface type which implements the "parent" interface.
+      Similarly, a classwide type is never an interface type.
+
+   2) We try to avoid having one section of the manual override another.
+      Is the definition
+          An interface type (also called an "interface") is a specific abstract
+          tagged type that is defined by an interface_type_definition.
+      "bad" in that sense? See 3.9.2(2) (the definition of a tagged type)
+      and 3.9.3(2) (the definition of an abstract type).
+
+   3) It is intended that in the case where the implementation
+      arbitrarily chooses one overrider from among group of inherited
+      subprograms, users should be unable to determine which
+      member was chosen.
+
+      In particular, users should be unable to do this by means of the
+      Access (or Unchecked_Access) attribute.
+
+      In order to accomplish this, and for other reasons, 4.5.2(13)'s rules
+      about access-to-subprogram equality need to be loosened further to allow
+      implementation-dependent results in the case of comparing access values
+      which denote distinct null subprograms.
+
+      That change is outside of the scope of this AI; it belongs in
+      the AI in which null procedures are defined.
+
+      Note that, formally speaking, the Address attribute poses no such
+      problems. Although the requirements of the marketplace may be much
+      more restrictive, the language itself allows an implementation
+      tremendous freedom with respect to Address attribute values
+      (see AI-173, 13.7.2(5)).
+
+   4) 12.5.5 refers to "the class of all interface types". Is there a
+      problem with having a class which is not closed with respect to
+      derivation? As noted above, a derived type is never an interface type.
+
+   5) There is no need to explicitly state that an interface type
+      shall not implement itself (just as circular derivations are
+      disallowed). This is a consequence of the rule that a partial
+      view of an interface must implement any interfaces which are
+      implemented by the full view.
+
+   6) Recommended level of support for representation items for
+      interface types = "confirmation only" ? Or perhaps no
+      representation items at all for interface types - only
+      operational items; would this be a legality rule or just the
+      recommended level of support?
+
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, September 26, 2002  6:28 PM
+
+> This is my attempt at incorporating the comments of the Vienna meeting
+> into AI-251.
+...
+> I'm not at all sure that these are all improvements, but I believe/hope that
+> they reflect the consensus of the group.
+
+Well, it might be useful to hear your objections...
+
+Nitpick: You use "which" where I would use "that" in most cases.
+(All except after ",".)
+
+You use "point" where the RM uses "place".
+
+> Discussion:
+>
+>    1) A derived type is never an interface type. One can derive from an
+>       interface type, but the result is not an interface. Instead, define
+>       a new interface type which implements the "parent" interface.
+>       Similarly, a classwide type is never an interface type.
+
+But interface'Class is legal, right?
+
+>    2) We try to avoid having one section of the manual override another.
+>       Is the definition
+>           An interface type (also called an "interface") is a specific
+>           abstract tagged type that is defined by an
+>           interface_type_definition.
+>       "bad" in that sense? See 3.9.2(2) (the definition of a tagged type)
+>       and 3.9.3(2) (the definition of an abstract type).
+
+There was a definite attempt in RM95 to put *all* the rules for abstract
+things together in one section.  It wouldn't hurt to preserve that.
+
+>    3) It is intended that in the case where the implementation
+>       arbitrarily chooses one overrider from among group of inherited
+>       subprograms, users should be unable to determine which
+>       member was chosen.
+>
+>       In particular, users should be unable to do this by means of the
+>       Access (or Unchecked_Access) attribute.
+>
+>       In order to accomplish this, and for other reasons, 4.5.2(13)'s rules
+>       about access-to-subprogram equality need to be loosened further to allow
+>       implementation-dependent results in the case of comparing access values
+>       which denote distinct null subprograms.
+
+I never liked that rule, but I guess you're right.
+
+>       That change is outside of the scope of this AI; it belongs in
+>       the AI in which null procedures are defined.
+>
+>       Note that, formally speaking, the Address attribute poses no such
+>       problems. Although the requirements of the marketplace may be much
+>       more restrictive, the language itself allows an implementation
+>       tremendous freedom with respect to Address attribute values
+>       (see AI-173, 13.7.2(5)).
+
+Right.
+
+>    4) 12.5.5 refers to "the class of all interface types". Is there a
+>       problem with having a class which is not closed with respect to
+>       derivation? As noted above, a derived type is never an interface type.
+
+Why is it not closed under derivation?  Oh, I see, a type derived from
+an interface is not an interface.  Well, yeah, it's bothersome to call
+that a "class".  I don't see an easy way around it.
+
+>    5) There is no need to explicitly state that an interface type
+>       shall not implement itself (just as circular derivations are
+>       disallowed). This is a consequence of the rule that a partial
+>       view of an interface must implement any interfaces which are
+>       implemented by the full view.
+
+Could use a NOTE.
+
+>    6) Recommended level of support for representation items for
+>       interface types = "confirmation only" ? Or perhaps no
+>       representation items at all for interface types - only
+>       operational items; would this be a legality rule or just the
+>       recommended level of support?
+
+I'm not sure what you're getting at here.  Interfaces have no
+components, so what's the "representation" issue.  Sure, I guess
+operational items should be allowed.... Is it necessary to say anything?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, September 27, 2002  4:12 PM
+
+> This is my attempt at incorporating the comments of the Vienna meeting
+> into AI-251.
+> ...
+>     --------
+>     3.9.4 Interface Types
+>         An interface type is an abstract tagged type intended for use
+>         in providing a restricted form of multiple inheritance.
+>         A tagged type may "implement" multiple interfaces, thereby allowing
+>         multiple views of objects of the type.
+>                                  Syntax
+>         interface_type_definition ::= [LIMITED] INTERFACE [WITH interface_list]
+>         interface_list ::= interface_subtype_mark {AND interface_subtype_mark}
+>                                  Legality Rules
+>         An interface type (also called an "interface") is a specific abstract
+>         tagged type that is defined by an interface_type_definition.
+
+This is not a legality rule.  It is static semantics (or simply a definition).
+
+>
+>         An interface type shall have no components.
+
+This is not a legality rule, so "shall have" => "has".
+This is the static semantics (since there is no way to specify
+components, it is silly to make this a legality/"shall" rule).
+
+>         All primitive operations of an interface type shall be abstract
+>         subprograms or null procedures.
+>
+>         The type of a subtype named in an interface_list shall be an
+>         interface type.
+>
+>         A descendant of a type which names an interface type in an
+>         interface_list, or which is derived from an interface type,
+>         is said to "implement" the interface and any other interfaces
+>         implemented by that interface.
+>         A class-wide type implements the interfaces implemented by the
+>         corresponding specific type. The corresponding full view of a
+>         partial view of a type implements all interfaces implemented by
+>         the partial view.
+
+More static semantics (no "shalls" in these).
+
+> ...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, September 27, 2002  8:21 PM
+
+Steve Baird wrote:
+
+> This is my attempt at incorporating the comments of the Vienna meeting
+> into AI-251.
+
+...
+
+Humm, I don't see any syntax for declaring that an original tagged type
+implements an interface. There is only syntax for declaring that on an
+extension. That doesn't seem right, why should it be necessary to declare an
+extra type in order to say that a new tagged type implements some interface?
+It also means that a private type which implements an interface cannot be
+completed by a tagged type that is not an extension.
+
+    type Root is tagged Window and record ...;
+
+I would expect a syntax like:
+    record_type_definition ::= [[abstract] tagged] [limited] [interface_list
+and] record_definition
+
+...
+
+>   In order to accomplish this, and for other reasons, 4.5.2(13)'s rules
+>   about access-to-subprogram equality need to be loosened further to allow
+>   implementation-dependent results in the case of comparing access values
+>   which denote distinct null subprograms.
+>
+>   That change is outside of the scope of this AI; it belongs in
+>   the AI in which null procedures are defined.
+
+What are you talking about? THIS is the AI where null procedures are defined!
+The ARG did not decide to split those out of this AI. We would do that only
+if there was a substantial chance that this AI would not be adopted while
+null procedures would be.
+
+---
+
+It would also be valuable if the !proposal summary and !discussion sections were
+updated to reflect the current proposal. They are getting way out of date,
+and I'm not sure if the implementation models, etc. still apply to this
+current wording.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 29, 2002  5:29 PM
+
+You just use the type extension syntax,
+but make the parent type be the interface.
+This is desirable so that a "normal" abstract tagged
+type may be changed into an interface
+type without changing any other code.
+
+As with "abstract", a type is not an
+interface unless the word "interface" appears
+in its definition.  Deriving from an interface
+does not make the derived type an interface.
+In fact, derived types are never interfaces.
+Interfaces are always considered "root" types
+that happen to implement other interfaces.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, September 29, 2002  6:44 PM
+
+Humm, that would work, but it would be completely inconsistent and unexpected.
+Moreover, what you would expect to do has no sensible way to indicate the
+correct thing to do. Indeed, the RM would be completely devoid on any
+indication of how to do this (as the derivation rules completely follow from
+existing language rules, and aren't being modified).
+
+My "mental image" of these things is that they are a new kind of item. If you
+want a type to "implement" an interface, you put the interface into an
+appropriate interface_list. That is not true in the case of derivation.
+
+Moreover, deriving from an interface gives a incorrect view of the
+(single-inheritance) type hierarchy. Such an derivation makes it appear that
+the new type is a member of the interface type. That's simply wrong, if the
+intent is to create a new hierarchy of types that happens to implement some
+interface.
+
+The fact that deriving these give a non-interface type is OK by me, but I view
+that is something that exists at all simply to avoid contract model problems
+with interfaces. Essentially, deriving one of these has to do SOMETHING, but
+its not something that you would ever do in new code. Yes, it's helpful in
+converting abstract types to interfaces, but I don't see that as something that
+will happen often (for two reasons: "if it ain't broke, don't fix it", and
+because most abstract types have concrete primitive operations, simply because
+they could).
+
+We'll have to dicuss this at the meeting.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 30, 2002  8:34 PM
+
+I consider it essential that interface types and
+abstract tagged types are very nearly interchangeable,
+and that you can go back and forth relatively
+easily, so long as the interface type is the first
+one listed after "new".
+
+The meaning of 'Class, "covers", implements, etc., should
+all be such that it makes very little difference in
+"type NT is new T with ..."
+whether T is an interface, or an abstract tagged type.
+
+At least I see that as an important goal.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, September 29, 2002  10:03 PM
+
+> I consider it essential that interface types and
+> abstract tagged types are very nearly interchangeable,
+> and that you can go back and forth relatively
+> easily, so long as the interface type is the first
+> one listed after "new".
+
+I don't think this will be possible most of the time, because interfaces allow
+multiple inheritance, and abstract types allow concrete operations and
+components. Usually one or the other will be a requirement.
+
+> The meaning of 'Class, "covers", implements, etc., should
+> all be such that it makes very little difference in
+> "type NT is new T with ..."
+> whether T is an interface, or an abstract tagged type.
+
+There certainly is value in keeping the proposal simple by reusing the abstract
+rules in the usage of these things. And, as I said, I really don't care what
+derivation means. What I object to is being required to make some random
+interface "more important" than the others by being required to derive from it
+when declaring the root of a type hierarchy. Just because some type happens to
+implement an interface doesn't make the interface a parent of the type
+hierarchy.
+
+Indeed, one could argue that is the problem with Controlled types. (However,
+they can't be an interface because they do have components - at least they do
+in Janus/Ada. Illustrating that point.)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent