CVS difference for ais/ai-00401.txt

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

--- ais/ai-00401.txt	2005/05/15 23:45:55	1.5
+++ ais/ai-00401.txt	2005/06/16 23:47:40	1.6
@@ -85,10 +85,10 @@
 Change 3.4(5) to read:
 
 If there is a record_extension_part, the derived type is called a record
-extension of the parent type. A record_extension_part {(and an interface_list)}
+extension of the parent type. A record_extension_part
 shall be provided if and only if the parent type is a tagged type.
+An interface_list shall be provided only if the parent type is a tagged type.
 
-
 Change 3.4(8) to read:
 
 Each class of types that includes the parent type {or a progenitor type} also
@@ -101,13 +101,14 @@
 operator -- see below) of the parent type {or of a progenitor type} that
 already exists at the place of the derived_type_definition, there exists a
 corresponding inherited primitive subprogram of the derived type with the same
-defining name. Primitive user-defined equality operators of the parent type are
-also inherited by the derived type, except when the derived type is a
-nonlimited record extension, and the inherited operator would have a profile
-that is type conformant with the profile of the corresponding predefined
-equality operator; in this case, the user-defined equality operator is not
-inherited, but is rather incorporated into the implementation of the predefined
-equality operator of the record extension (see 4.5.2).
+defining name. Primitive user-defined equality operators of the parent type
+{and any progenitor types} are also inherited by the derived type, except when
+the derived type is a nonlimited record extension, and the inherited operator
+would have a profile that is type conformant with the profile of the
+corresponding predefined equality operator; in this case, the user-defined
+equality operator is not inherited, but is rather incorporated into the
+implementation of the predefined equality operator of the record extension (see
+4.5.2).
 
 
 Change 3.4(18) to read:
@@ -165,7 +166,8 @@
 Change the second sentence of 3.4.1(2) as modified by AI95-00251 to read:
 
 A derived type, interface type, type extension, task type, protected type, or
-formal derived type is also derived from each of its progenitor types, if any.
+formal derived type is also derived from every ancestor of each of its
+progenitor types, if any.
 
 
 Change 7.3(16) to read:
@@ -213,7 +215,7 @@
 Change 12.5.1(21) to read:
 
 For a formal derived type, the predefined operators and inherited user-defined
-subprograms are determined by the ancestor type {and the progenitor types}, and
+subprograms are determined by the ancestor type {and any progenitor types}, and
 are implicitly declared at the earliest place, if any, immediately within the
 declarative region in which the formal type is declared , where the
 corresponding primitive subprogram of the ancestor {or progenitor} is visible
@@ -267,9 +269,11 @@
 provided if and only if the parent type is a tagged type.
 @dby
 If there is a @fa<record_extension_part>, the derived type is called a
-@i<record extension> of the parent type. A @fa<record_extension_part> (and an
-@fa<interface_list>) shall be provided if and only if the parent type is a
-tagged type.
+@i<record extension> of the parent type. A @fa<record_extension_part>
+shall be provided if and only if the parent type is a
+tagged type. An @fa<interface_list> shall be provided only if the parent type
+is a tagged type.
+
 
 !corrigendum 3.4(08)
 
@@ -284,7 +288,7 @@
 
 @drepl
 @xbullet<For each user-defined primitive subprogram (other than a user-defined
-equality operator -- see below) of the parent type that already exists at the
+equality operator @emdash see below) of the parent type that already exists at the
 place of the @fa<derived_type_definition>, there exists a corresponding
 @i<inherited> primitive subprogram of the derived type with the same defining
 name. Primitive user-defined equality operators of the parent type are also
@@ -296,16 +300,17 @@
 of the record extension (see 4.5.2).>
 @dby
 @xbullet<For each user-defined primitive subprogram (other than a user-defined
-equality operator -- see below) of the parent type or of a progenitor type that
+equality operator @emdash see below) of the parent type or of a progenitor type that
 already exists at the place of the @fa<derived_type_definition>, there exists a
 corresponding @i<inherited> primitive subprogram of the derived type with the
 same defining name. Primitive user-defined equality operators of the parent
-type are also inherited by the derived type, except when the derived type is a
-nonlimited record extension, and the inherited operator would have a profile
-that is type conformant with the profile of the corresponding predefined
-equality operator; in this case, the user-defined equality operator is not
-inherited, but is rather incorporated into the implementation of the predefined
-equality operator of the record extension (see 4.5.2).>
+type and any progenitor types are also inherited by the derived type, except
+when the derived type is a nonlimited record extension, and the inherited
+operator would have a profile that is type conformant with the profile of the
+corresponding predefined equality operator; in this case, the user-defined
+equality operator is not inherited, but is rather incorporated into the
+implementation of the predefined equality operator of the record extension (see
+4.5.2).>
 
 !corrigendum 3.4(18)
 
@@ -332,12 +337,12 @@
 The same formal parameters have @fa<default_expression>s in the profile of the
 inherited subprogram. Any type mismatch due to the systematic replacement of
 the parent type by the derived type is handled as part of the normal type
-conversion associated with parameter passing -- see 6.4.1.
+conversion associated with parameter passing @emdash see 6.4.1.
 @dby
 The same formal parameters have @fa<default_expression>s in the profile of the
 inherited subprogram. Any type mismatch due to the systematic replacement of
 the parent or progenitor type by the derived type is handled as part of the
-normal type conversion associated with parameter passing -- see 6.4.1.
+normal type conversion associated with parameter passing @emdash see 6.4.1.
 
 !corrigendum 3.4(23)
 
@@ -400,11 +405,11 @@
 A derived type is @i<derived from> its parent type @i<directly>; it is derived
 @i<indirectly> from any type from which its parent type is derived. A derived
 type, interface type, type extension, task type, protected type, or formal
-derived type is also derived from each of its progenitor types, if any. The
-derivation class of types for a type @i<T> (also called the class @i<rooted> at
-@i<T>) is the set consisting of @i<T> (the @i<root type> of the class) and all
-types derived from @i<T> (directly or indirectly) plus any associated universal
-or class-wide types (defined below).
+derived type is also derived from every ancestor of each of its progenitor
+types, if any. The derivation class of types for a type @i<T> (also called the
+class @i<rooted> at @i<T>) is the set consisting of @i<T> (the @i<root type> of
+the class) and all types derived from @i<T> (directly or indirectly) plus any
+associated universal or class-wide types (defined below).
 
 !corrigendum 7.3(16)
 
@@ -570,7 +575,7 @@
 be that corresponding to the actual type.
 @dby
 For a formal derived type, the predefined operators and inherited user-defined
-subprograms are determined by the ancestor type and the progenitor types, and
+subprograms are determined by the ancestor type and any progenitor types, and
 are implicitly declared at the earliest place, if any, immediately within the
 declarative region in which the formal type is declared, where the
 corresponding primitive subprogram of the ancestor or progenitor is visible
@@ -605,4 +610,79 @@
 
 !appendix
 
+From: Erhard Ploedereder
+Sent: Tuesday, May 3, 2005  12:05 PM
+
+
+The connection between "implemented_by" and "overridden by parent" that I
+am/was worried about......
+
+below is a description of what I was worried about -- however, meanwhile I
+discovered that one sentence may save the day, i.e., makes my worrisome
+examples illegal. The sentence is 3.4 (5/2, 2.sentence) in the version as I
+have corrected the sentence. If the original version stays, you definitely
+need to read on. The (corrected) sentence expresses the rule: have an
+interface_list in a derived type definition, then the parent must be tagged
+(which a task type is not).  The original rule poses the rule only if it is
+a record extension part as well, making my examples legal (and troublesome).
+
+The situation that I worried about starts out by the following:
+
+task type T is
+   entry do_this;
+end T;
+
+interface I;
+   procedure do_this(X: I);
+
+type NT is new T and I;
+
+vs.
+
+task type NNT is new I with
+   entry do_this;
+end NNT;
+
+Compare NNT and NT. For NNT, clearly the entry implements I.do_this.
+For NT, does it, too? It looks like "no, it doesn't" since the entry
+of NT isn't declared top-level and hence no homograph to the inherited
+I.do_this.
+
+Lawyerly logical, "userly" a surprise when it works for NNT, but not for NT.
+
+If this isn't fixed (or isn't so in the first place) then the one that
+really worries me lawyerly and userly is
+
+type N3T is new NT and NI;      - NI a descendant of I
+
+For N3T, although the entry NT.do_it implements I.do_it, this won't be
+recognized and there will be an obligation to override NI.do_it, although it
+is I.do_it.
+
+---
+by a rather narrow margin, the following problem is avoided because prefixed
+views require a tagged type object, which tasks aren't, and hence prefix
+call notation is not available for the call to a subprog inherited from an
+interface.
+
+X: N3T;
+...
+X.do_it;
+
+could be either a call on the entry or a prefix-notation call to the
+inherited (and overridden) NI.do_it. (Of course, with a "unified view"
+it wouldn't be a problem, since it's all one and the same.)
+
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, May 3, 2005  1:38 PM
+
+I think your version is what was intended; there is no intention to allow
+derivation from a task type that has interfaces, or to allow derivation to
+add interfaces without extension.
+
+So we can ignore the rest of your explanation. Thank goodness. :-)
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent