CVS difference for ais/ai-00195.txt

--- ais/ai-00195.txt	1999/11/23 23:58:33	1.11
+++ ais/ai-00195.txt	2000/07/08 02:40:52	1.12
@@ -1,4 +1,4 @@
-!standard 13.13.1 (00)                                99-09-23  AI95-00195/05
+!standard 13.13.1 (00)                                00-07-07  AI95-00195/06
 !class binding interpretation 98-03-27
 !status work item 98-04-04
 !status received 98-03-27
@@ -19,18 +19,17 @@
 attribute_definition_clause.  A stream-oriented attribute may be specified
 before the type has been fully defined.
 
-3 - For a derived type which is limited (tagged or not), the attributes Read
-and Write are inherited, and the attributes Input and Output revert to their
-predefined definition (i.e. they cannot be called).  (This amends AI95-
-00108.)
+3 - For a limited tagged type T, if Read is specified for an ancestor type of T,
+then T'Class'Read, T'Input, and T'Class'Input can be called, even if these are
+not specified. Similarly, if Write is specified for an ancestor type of T,
+then T'Class'Write, T'Output, and T'Class'Output can be called.
 
 4 - In the profiles of the stream-oriented attributes, the notation
 "italicized T" refers to the base subtype for a scalar type, and to the first
 subtype otherwise.
 
-5 - For an untagged derived type with new discriminants that have defaults,
-the predefined stream-oriented attributes read or write the new
-discriminants, not the old ones.  (This amends AI95-00108.)
+5 - In an attribute_definition_clause for a stream-oriented attribute, the
+name shall not denote an abstract subprogram.
 
 6 - The predefined Read attribute for composite types with defaulted
 discriminants must ensure that, if exceptions are raised by the Read
@@ -59,9 +58,6 @@
 subtype of the type.  Constraint_Error is raised if such an attribute is
 passed (or would return) a value outside the range of the first subtype.
 
-11 - In an attribute_definition_clause for a stream-oriented attribute, the
-name shall not denote an abstract subprogram.
-
 !question
 
 1 - RM95 13.13.2(27) states that S'Input "creates an object (with the bounds
@@ -84,26 +80,15 @@
 reference to the attribute legal? (no)
 
 3 - Let T be a limited type with an attribute_definition_clause for attribute
-Read, and D a type derived from T, and assume that there is no
-attribute_definition_clause for D'Read.  Is a usage of D'Read legal? (yes)
+Read. Is a usage of T'Class'Read legal? (yes)
 
 4 - The definition of the profiles of S'Read, S'Write, S'Input
 and S'Output given in RM95 13.13.2 uses the notation "italicized T" for the
 type of the Item parameter.  What is the meaning of "italicized T" in this
 context? (T'Base for scalars, first subtype otherwise.)
-
-5 - AI95-00108 states (in the !discussion section) that "for untagged derived
-types, there is no problem for the derived type inheriting the stream
-attributes."
 
-This doesn't seem clear if the derived type includes a known discriminant
-part.  Consider:
-
-        type Parent (D1, D2 : Integer := 1) is ...;
-        type Child (D : Integer := 2) is new Parent (D1 => D, D2 => D);
-
-Clearly Parent'Write writes two discriminant values.  How many discriminants
-does Child'Write write? (one)
+5 - In an attribute_definition_clause for a stream attribute, is it legal to
+give a name that denotes an abstract subprogram? (no)
 
 6 - RM95 13.13.2(9) states that for a record type, the predefined S'Read reads
 the components in positional aggregate order.  However, the language doesn't
@@ -142,9 +127,6 @@
 portability, and makes it difficult to use streams to match a file format
 defined externally to Ada.
 
-11 - In an attribute_definition_clause for a stream attribute, is it legal to
-give a name that denotes an abstract subprogram? (no)
-
 !recommendation
 
 (See summary.)
@@ -214,23 +196,29 @@
 "representation attributes", do not actually affect the representation of the
 type."  Therefore, we must amend RM95 13.1(9) so that it doesn't apply to the
 stream-oriented attributes.
+
+
+3 - The rules given in 13.13.2(36) (as amended by 8652/0040 [AI-00108]),
+say that "All nonlimited types have default implementations for these
+operations." However, many limited types also have default implementations
+for these operations; yet they may not be called.
+
+The rules given in AI-108 insure that if a limited tagged ancestor type
+has a valid, callable 'Read attribute, then all of types derived
+from that ancestor also have a valid 'Read attribute. Therefore,
+dispatching to the operation is safe, and there is no need to prohibit calls
+to T'Class'Read in that case. Similar logic applies to 'Write.
+
+Similarly, the default implementation of T'Input is defined in terms of
+T'Read. If T'Read is callable, then the implementation of T'Input is
+well-defined as well, and there is no reason to prohibit calls. A similar
+argument applies to T'Output when T'Write is callable. Finally, if T'Input
+is callable, then T'Class'Input is well-defined, and also should be callable.
 
-3 - AI95-00108 states that "for a type extension, the predefined Read
-attribute is defined to call the Read of the parent type, followed by
-the Read of the non-inherited components, if any, in canonical order."
-
-This rule doesn't work for limited (tagged) types, because the non-
-inherited components might include protected objects or tasks for which
-the predefined Read and Write attributes cannot be called.
-
-For limited derived types (tagged or not), the only sensible rule is
-that Read and Write are inherited "as is".  This is consistent with what
-happens with the operator "=".  On the other hand the attributes Input
-and Output cannot be inherited, as explained in the discussion of AI95-
-00108.  Therefore, these attributes must revert to their predefined
-definition, which means that they cannot be called, as stated in RM95
-13.13.2(36).
+Therefore, 13.13.2(36) should allow calling any of these attributes if the
+appropriate 'Read (or 'Write) is defined.
 
+
 4 - AI95-00145 specifies the meaning of the notation "italicized T" for
 operators as follows:
 
@@ -256,35 +244,17 @@
 
      - T'Base, for scalars
      - the first subtype, in other cases
-
-5 - The inheritance rule given in AI95-00108 should only apply to those
-attributes that have been specified for the parent type.
 
-If this rule was applied to the predefined stream-oriented attributes, it
-would require, in the example given, to read or write two discriminants,
-because the predefined Read and Write attributes of type Parent do read or
-write two discriminants.  But that would be inconsistent with the rule given
-in RM95 13.13.2(9): "the Read or Write attribute for each component is called
-in canonical order," since D1 and D2 are not components of type Child.
-
-Furthermore, definiteness can be changed by type derivation, and the dynamic
-semantics of Read and Write depend on definiteness.  Consider the following
-modification of the original example:
+5 - Obviously it should not be possible to perform a non-dispatching call to
+an abstract subprogram (stream-oriented attributes are always called in a
+non-dispatching manner).  Therefore, we have two options:
 
-        type Parent (D1, D2 : Integer) is ...;
-        type Child (D : Integer := 2) is new Parent (D1 => D, D2 => D);
+   - Make the attribute_definition_clause illegal.
+   - Make the calls (explicit or implicit) illegal.
 
-In this case the predefined stream-oriented attributes for type Parent do not
-read or write the discriminants, so applying the inheritance rule of AI95-
-00108 would cause the stream-oriented attributes for Child to not read or
-write any discriminant, which doesn't make sense.
-
-Therefore, RM95 13.13.2(9) must have precedence, and the predefined stream-
-oriented attributes for Child only read or write exactly one discriminant, D.
-
-The underlying model is that the predefined stream-oriented attributes are
-created anew for each type declaration, based on the structure of the type,
-much like predefined operators.
+The second option is a significant implementation burden, and allowing the
+attribute_definition_clause only to reject all calls doesn't seem to do any
+good.  That's why the first option was preferred.
 
 6 - The problem mentioned in the question only exists for a type R that is
 passed by-reference to R'Read: obviously if the type is passed by copy, an
@@ -419,17 +389,6 @@
      range of the first subtype, Constraint_Error is raised.  This check is a
      Range_Check.
 
-11 - Obviously it should not be possible to perform a non-dispatching call to
-an abstract subprogram (stream-oriented attributes are always called in a
-non-dispatching manner).  Therefore, we have two options:
-
-   - Make the attribute_definition_clause illegal.
-   - Make the calls (explicit or implicit) illegal.
-
-The second option is a significant implementation burden, and allowing the
-attribute_definition_clause only to reject all calls doesn't seem to do any
-good.  That's why the first option was preferred.
-
 !appendix
 
 !section 13.13.1
@@ -3047,6 +3006,41 @@
 will probably simplify the solution enough to not justify adding any
 declarations to Ada.Exceptions.
 
--Tuck
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, June 01, 2000 9:25 PM
+
+...
+I would suggest that Output and Input piggy back automatically
+on Write and Read, even for limited types:
+If the Read attribute of a type can legally be called, then the Input
+attribute has a non-abstract default implementation; similarly,
+if the Write attribute of a type can legally be called, then
+the Output attribute has a non-abstract default implementation.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 02, 2000 5:12 PM
+
+This seems like a good idea, but it's going well beyond the AI, or even what is
+currently in AI-00195. I don't want to bog the corrigendum down at the last
+minute with good ideas... I suggest that we add that to AI-195.
+
+Clearly, this wouldn't conflict with the current wording (which defines that
+these always use the default implementation, but leaves them uncallable for
+limited types). But I'm not sure it is useful for the implementation burden --
+Input is a function after all, and limited functions aren't very useful.
+
+****************************************************************
+
+Editor's note, 7/7/2000
+
+Original questions 3 & 5 were deleted, as they have been handled in the
+corrigendum wording for AI-108.
+
+I also added Tucker's suggestion to the AI as question 3, and moved up
+question 11 to take the space of question 5.
 
 ****************************************************************