CVS difference for ais/ai-00195.txt

Differences between 1.16 and version 1.17
Log of other versions for file ais/ai-00195.txt

--- ais/ai-00195.txt	2001/09/08 01:42:47	1.16
+++ ais/ai-00195.txt	2001/09/08 03:35:05	1.17
@@ -1,4 +1,4 @@
-!standard 13.13.1 (00)                                00-11-14  AI95-00195/07
+!standard 13.13.1 (00)                                01-08-31  AI95-00195/08
 !class binding interpretation 98-03-27
 !status work item 98-04-04
 !status received 98-03-27
@@ -14,15 +14,14 @@
 undergoes default initialization and finalization.
 
 2 - For the purposes of checking legality rules, it is necessary to determine
-whether a stream-oriented attribute has been specified for a limited type (RM95
-13.13.2(36)). This is done by applying the normal visibility rules to the
-attribute_definition_clause.  A stream-oriented attribute may be specified
-before the type has been fully defined.
-
-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.
+whether a stream-oriented attribute has been specified for a limited type
+(13.13.2(36)). This is done by applying the normal visibility rules to the
+attribute_definition_clause.
+
+3 - For a limited tagged type T, if Read is available then T'Input is
+available, even if it is not specified. Similarly, if Write is available then
+T'Output is available. T'Class'Read, T'Class'Write, T'Class'Input and
+T'Class'Output are not available unless they are specified.
 
 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
@@ -34,7 +33,7 @@
 6 - The predefined Read attribute for composite types with defaulted
 discriminants must ensure that, if exceptions are raised by the Read
 attribute for some discriminant, the discriminants of the actual object
-passed to Read are not modified.  This may require the creation of an
+passed to Read are not modified. This may require the creation of an
 anonymous object, which undergoes initialization and finalization.
 
 7 -The predefined Read attribute for composite types with defaulted
@@ -47,48 +46,48 @@
 attribute_definition_clause.
 
 9 - The number of calls performed by the predefined implementation of the
-stream-oriented attributes to the Read and Write operations of the stream
-type is unspecified (an implementation may take advantage of this rule to
-perform internal buffering). However, all the calls to Read and Write needed
-to  implement a top-level invocation of a stream-oriented attribute must take
-place before this top-level invocation returns.
+stream-oriented attributes on the Read and Write operations of the stream type
+is unspecified. An implementation may take advantage of this permission to
+perform internal buffering. However, all the calls on the Read and Write
+operations of the stream type needed to implement an explicit invocation of a
+stream-oriented attribute must take place before this invocation returns.
 
 !question
 
-1 - RM95 13.13.2(27) states that S'Input "creates an object (with the bounds
+1 - 13.13.2(27) states that S'Input "creates an object (with the bounds
 or discriminants, if any, taken from the stream), initializes it with S'Read,
 and returns the value of the object."
 
 Does the verb "initialize" in this sentence refer to the entire initialization
-process mentioned in RM95 3.3.1(18) and 7.6(10)? (yes) In particular, if S is
+process mentioned in 3.3.1(18) and 7.6(10)? (Yes.) In particular, if S is
 a controlled subtype, or if it contains controlled components, is the
-Initialize subprogram called?  (yes) Is the Finalize subprogram called when
-the intermediate object is finalized?  (yes) For a record type whose
-components have initial values, are these values evaluated? (yes)
+Initialize subprogram called? (Yes.) Is the Finalize subprogram called when
+the intermediate object is finalized? (Yes.) For a record type whose
+components have initial values, are these values evaluated? (Yes.)
 
-2 - RM95 13.13.2(36) states that "an attribute_reference for one of these
+2 - 13.13.2(36) states that "an attribute_reference for one of these
 attributes is illegal if the type is limited, unless the attribute has been
 specified by an attribute definition clause."
 
 If some stream-oriented attribute has been specified in a private part, and we
 are at a point that doesn't have visibility over that private part, is a
-reference to the attribute legal? (no)
+reference to the attribute legal? (No.)
 
 3 - Let T be a limited type with an attribute_definition_clause for attribute
-Read. Is a usage of T'Class'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
+and S'Output given in 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 - In an attribute_definition_clause for a stream attribute, is it legal to
-give a name that denotes an abstract subprogram? (no)
+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
+6 - 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
 seem to specify what happens when exceptions are raised by the calls to the
-Read attribute for the components.  Consider for example the following type
+Read attribute for the components. Consider for example the following type
 declarations:
 
         type T1 is range ...;
@@ -100,28 +99,28 @@
            end record;
 
 Say that attributes_definition_clauses have been given for T1'Read and
-T2'Read, and consider a call to R'Read.  Assume that, during this call, an
-exception is raised by T2'Read.  Is the discriminant X.D1 modified? (no)
+T2'Read, and consider a call to R'Read. Assume that, during this call, an
+exception is raised by T2'Read. Is the discriminant X.D1 modified? (No.)
 
 7 - Consider a call to T'Read where T is a type with defaulted discriminants.
 If the discriminants found in the stream have values different from those of
 the discriminants of the object passed to T'Read for the Item parameter, and
-that object is constrained, is Constraint_Error raised? (yes)
+that object is constrained, is Constraint_Error raised? (Yes.)
 
-8 - If T is an abstract type, is the function T'Input abstract? (no, but it
-cannot be called)
+8 - If T is an abstract type, is the function T'Input abstract? (No, but it
+cannot be called.)
 
-9 - RM95 13.13.1(1) states that "T'Read and T'Write make dispatching calls on
+9 - 13.13.1(1) states that "T'Read and T'Write make dispatching calls on
 the Read and Write procedures of the type Root_Stream_Type."  Is the number of
-those calls specified? (no)
+those calls specified? (No.)
 
 !recommendation
 
-(See summary.)
+(See Summary.)
 
 !wording
 
-(See summary.)
+(See Corrigendum.)
 
 !discussion
 
@@ -136,14 +135,15 @@
            S'Read (..., Anon);
         end;
 
-Accordingly, the initialization described in RM95 3.3.1(8-9) and RM95 7.6(10)
-takes place when Anon is declared, and the finalization described in RM95
-7.6.1 takes place when Anon disappears (and before returning from the call to
+Accordingly, the initialization described in 3.3.1(8-9) and 7.6(10)
+takes place when Anon is declared, and the finalization described in 7.6.1
+takes place when Anon disappears (and before returning from the call to
 S'Input).
 
 Note that as part of initialization, compiler-specific fields are initialized
 as required by the implementation (and as permitted by AARM 3.3.1(14.a)).
 
+
 2 - Consider for example:
 
         package P is
@@ -163,38 +163,87 @@
 
 The call to P.T'Read is illegal, because Q doesn't have visibility over the
 private part of P, which contains the attribute_definition_clause for
-attribute Read.  On the other hand, at a place that has visibility over the
+attribute Read. On the other hand, at a place that has visibility over the
 private part of P (and that comes after the attribute_definition_clause) a
-reference to T'Read is legal.  This rule is necessary to preserve the privacy
+reference to T'Read is legal. This rule is necessary to preserve the privacy
 of private types.
 
 Note that it is the location of the attribute_definition_clause that counts,
-not that of the subprogram specified in that clause.  Thus, if the procedure
+not that of the subprogram specified in that clause. Thus, if the procedure
 Read above were moved to the visible part of P, a reference to P.T'Read would
 still be illegal (but a reference to P.Read wouldn't).
 
+Because the stream attributes are operational attributes (13.13.2(1/1)), an
+attribute_definition_clause may be given before the type is fully defined.
 
-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.
 
-Therefore, 13.13.2(36) should allow calling any of these attributes if the
-appropriate 'Read (or 'Write) is defined.
+3 - In order to simplify the discussion, we first define a new term: a stream-
+oriented attribute is "available" at some place in the program text if an
+attribute_reference for that attribute is (or would be) legal at that place.
+
+The rules given in 13.13.2(9/1) try to insure that if the Read attribute
+is available for a limited tagged ancestor type, then it as also available for
+all of the types derived from that ancestor. However, this is not true because
+this rule fails to take into account the visibility issues mentioned in item #2
+above. Consider for example:
 
+        package P is
+           type T is tagged limited private;
+        private
+           type T is new Boolean;
+           for T'Read use ...
+        end P;
 
+        with P;
+        package Q is
+           protected type Prot is ... end Prot;
+           type NT is new T with
+              record
+                 C : Prot;
+              end record;
+           -- No need to define Read (13.13.2(9/1))
+        end Q;
+
+        with Q;
+        package body P is
+           type NNT is new NT with null record;
+           ...
+           NNT'Read (...); -- Legal?
+        end P;
+
+Because the attribute_definition_clause for P.T'Read is not visible at the
+place where NT is declared, 13.13.2(9/1) does not apply, and it is
+therefore not necessary to define the Read attribute for Q.NT. However, when we
+come to the declaration of NNT, we want to ensure that NNT is not callable,
+because we have no mechanism for reading the component C. Instead of depending
+on whether the attribute has been specified for some ancestor type,
+13.13.2(36/1) must depend on whether the attribute is available for the parent
+type (and for the types of the extension components).
+
+Moreover, dispatching to the Read attribute does not work: there is no
+guarantee that all the types derived from T will have an available Read
+attribute. So the attribute Read is not available for T'Class.
+
+The default implementation of T'Input is defined in terms of T'Read. If T'Read
+is available, 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 available. But T'Class'Input and T'Class'Output are both
+unavailable.
+
+The above model is unfortunately not what is stated by the rules in
+13.13.2(36/1). These rules seem to imply that a reference to Input (resp.
+Output) is legal for the type extension if Input (resp. Output) is available
+for the parent type. This is incorrect because the default implementation of
+Input and Output calls Read or Write for the same type, not Input or Output
+for the parent type. It should say that a reference to Input (resp. Output)
+is legal for the type extension if Read (resp. Write) is available for that
+type.
+
+Given that the class-wide stream attributes cannot be available for limited
+tagged types, the last sentence of 13.13.2(9/1) becomes useless, and might
+as well be removed.
+
+
 4 - AI95-00145 specifies the meaning of the notation "italicized T" for
 operators as follows:
 
@@ -206,12 +255,12 @@
 
 In the case of stream-oriented attributes the notation "italicized T" must be
 consistent with the parameter subtype required for
-attribute_definition_clauses.  If we chose the same rule as for operators, we
+attribute_definition_clauses. If we chose the same rule as for operators, we
 would have a discrepancy in the case of constrained untagged types, and this
 would unnecessarily complicate the static and dynamic semantics.
 
 When one of the stream-oriented attributes is specified by an attribute
-definition clause, RM95 13.13.2(36) states that "the subtype of the Item
+definition clause, 13.13.2(36) states that "the subtype of the Item
 parameter shall be the base subtype if scalar, and the first subtype
 otherwise."
 
@@ -221,17 +270,19 @@
      - T'Base, for scalars
      - the first subtype, in other cases
 
+
 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:
+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.
+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
 exception raised by R'Read cannot affect the original object.
@@ -240,30 +291,30 @@
 cases:
 
    - If the exception in T2'Read is due to the failure of some
-     language-defined check, RM95 11.6(6) explains that the object or its
+     language-defined check, 11.6(6) explains that the object or its
      parts may become abnormal, so we don't have to specify what happens to
      the discriminants.
 
    - If the exception in T2'Read is due to an explicit raise, the object
      obviously doesn't become abnormal, and therefore we must preserve the
-     integrity of its discriminants.  In other words, either all discriminants
+     integrity of its discriminants. In other words, either all discriminants
      are updated (if the calls to the Read attributes for the discriminants
      were successful) or none (if any call to a Read attribute for a
      discriminant raised an exception).
 
 This model requires an implementation to read the discriminants, create an
 anonymous object using the given discriminants and assign that object to the
-formal parameter Item.  The normal initialization and finalization take place
+formal parameter Item. The normal initialization and finalization take place
 for this anonymous object.
 
 Strictly speaking, the use of an anonymous object is only required for a type
 with defaulted discriminants which is passed by-reference, if the actual
-parameter of Read is not constrained.  However, an implementation is free to
+parameter of Read is not constrained. However, an implementation is free to
 use anonymous objects in other cases.
 
-Use of an anonymous object is only required for discriminants.  An
+Use of an anonymous object is only required for discriminants. An
 implementation is free to read the other components directly in the Item
-parameter.  For example, if we change the original example as follows:
+parameter. For example, if we change the original example as follows:
 
       type R is
          record
@@ -274,21 +325,24 @@
 then if T2'Read raises an exception when reading component C2, it is
 unspecified if C1 is modified or not.
 
+
 7 - When the type has defaulted discriminants, the predefined Read attribute
-must read them from the stream.  It can be the case that the actual object
-passed to Read is constrained.  In this case, the discriminants found in the
-stream may or may not match those of the actual.  If they don't match,
+must read them from the stream. It can be the case that the actual object
+passed to Read is constrained. In this case, the discriminants found in the
+stream may or may not match those of the actual. If they don't match,
 Constraint_Error is raised, and this is a Discriminant_Check.
 
 It is unspecified whether this effect is achieved by assigning a temporary
 object, as explained in #6 above, or by other means.
 
+
 8 - If T is an abstract type, calling the function T'Input would effectively
-create an object whose tag designates T, which is absurd.  We could decide
+create an object whose tag designates T, which is absurd. We could decide
 that T'Input is abstract, but it seems simpler to say that any
 attribute_reference for this attribute is illegal, by analogy with the rule
-stated in RM95 13.13.2(36) for limited types.
+stated in 13.13.2(36) for limited types.
 
+
 9 - Surely the user could count the calls to the Read and Write operations
 for the stream type by writing a perverse implementation of these operations,
 but it seems that performance should have precedence: for the predefined
@@ -297,15 +351,166 @@
 
 Therefore, the number of calls to the Read and Write operations is
 unspecified, and implementations are free (and in fact advised) to do
-internal buffering.  However, we don't want to allow an implementation to
+internal buffering. However, we don't want to allow an implementation to
 buffer all stream output and do only one call to Write when the program
 terminates: the user must be able to assume reasonable properties regarding
-the underlying buffering mechanism.  That's why we require that all the calls
+the underlying buffering mechanism. That's why we require that all the calls
 to Read or Write take place before the top-level call to a stream-oriented
-attribute completes.  In other words, an implementation may combine several
+attribute completes. In other words, an implementation may combine several
 consecutive calls to Write into a single one, provided these calls all
 pertain to a single top-level call to the attribute Write (or Output).
 
+!corrigendum 13.13.2(1/1)
+
+@dinsa
+The operational attributes Write, Read, Output, and Input convert values to a
+stream of elements and reconstruct values from a stream.
+@dinst
+The subtype of the Item parameter of the stream-oriented attributes is the base
+subtype of @i<T> if @i<T> is a scalar type, and the first subtype otherwise.
+The same rule applies to the result of the Input attribute.
+
+!corrigendum 13.13.2(9/1)
+
+@drepl
+For elementary types, the representation in terms of stream elements is
+implementation defined. For composite types, the Write or Read attribute for
+each component is called in canonical order, which is last dimension varying
+fastest for an array, and positional aggregate order for a record. Bounds are
+not included in the stream if @i<T> is an array type. If @i<T> is a
+discriminated type, discriminants are included only if they have defaults.
+If @i<T> is a tagged type, the tag is not included. For type extensions, the
+Write or Read attribute for the parent type is called, followed by the
+Write or Read attribute of each component of the extension part, in canonical
+order. For a limited type extension, if the attribute of any ancestor type of
+@i<T> has been directly specified and the attribute of any ancestor type of
+the type of any of the extension components which are of a limited type has
+not been specified, the attribute of @i<T> shall be directly specified.
+@dby
+For elementary types, the representation in terms of stream elements is
+implementation defined. For composite types, the Write or Read attribute for
+each component is called in canonical order, which is last dimension varying
+fastest for an array, and positional aggregate order for a record. Bounds are
+not included in the stream if @i<T> is an array type. If @i<T> is a
+discriminated type, discriminants are included only if they have defaults.
+If @i<T> is a tagged type, the tag is not included. For type extensions, the
+Write or Read attribute for the parent type is called, followed by the Write
+or Read attribute of each component of the extension part, in canonical order.
+
+!corrigendum 13.13.2(27)
+
+@drepl
+S'Output then calls S'Write to write the value of Item to the stream. S'Input
+then creates an object (with the bounds or discriminants, if any, taken from
+the stream), initializes it with S'Read, and returns the value of the object.
+@dby
+S'Output then calls S'Write to write the value of Item to the stream. S'Input
+then creates an object (with the bounds or discriminants, if any, taken from
+the stream), initializes it with S'Read, and returns the value of the object.
+The normal initialization and finalization take place for this object (see
+3.3.1, 7.6, 7.6.1).
+
+!corrigendum 13.13.2(35)
+
+@drepl
+In the default implementation of Read and Input for a composite type, for each
+scalar component that is a discriminant or whose @fa<component_declaration>
+includes a @fa<default_expression>, a check is made that the value returned by
+Read for the component belongs to its subtype. Constraint_Error is raised if
+this check fails. For other scalar components, no check is made. For each
+component that is of an access type, if the implementation can detect that
+the value returned by Read for the component is not a value of its subtype,
+Constraint_Error is raised. If the value is not a value of its subtype and
+this error is not detected, the component has an abnormal value, and erroneous
+execution can result (see 13.9.1).
+@dby
+In the default implementation of Read and Input for a composite type, for each
+scalar component that is a discriminant or whose @fa<component_declaration>
+includes a @fa<default_expression>, a check is made that the value returned by
+Read for the component belongs to its subtype. Constraint_Error is raised if
+this check fails. For other scalar components, no check is made. For each
+component that is of an access type, if the implementation can detect that
+the value returned by Read for the component is not a value of its subtype,
+Constraint_Error is raised. If the value is not a value of its subtype and
+this error is not detected, the component has an abnormal value, and erroneous
+execution can result (see 13.9.1). In the default implementation of Read for a
+composite type with defaulted discriminants, if the actual parameter of Read is
+constrained, a check is made that the discriminants read from the stream are
+equal to those of the actual parameter. Constraint_Error is raised if this
+check fails.
+
+If Constraint_Error is raised during a call on Read because of failure of one
+the above checks, the implementation must ensure that the discriminants of the
+actual parameter of Read are not modified. It is unspecified how this effect is
+achieved.
+
+!corrigendum 13.13.2(36/1)
+
+@drepl
+The stream-oriented attributes may be specified for any type via an
+@fa<attribute_definition_clause>. All nonlimited types have default
+implementations for these operations. An @fa<attribute_reference> for one of
+these attributes is illegal if the type is limited, unless the attribute
+has been specified by an @fa<attribute_definition_clause> or (for a type
+extension) the attribute has been specified for an ancestor type. For an
+@fa<attribute_definition_clause> specifying one of these attributes, the
+subtype of the Item parameter shall be the base subtype if scalar, and the
+first subtype otherwise. The same rule applies to the result of the Input
+function.
+@dby
+The stream-oriented attributes may be specified for any type via an
+@fa<attribute_definition_clause>. The subprogram name given in such a
+clause shall not denote an abstract subprogram.
+
+A stream-oriented attribute for a subtype of a specific type @i<T> is
+@i<available> at places where one of the following conditions is true:
+@xbullet<The attribute_designator is Read, Write or Output, and @i<T>
+is nonlimited.>
+@xbullet<The attribute_designator is Input, and @i<T> is nonlimited
+and not abstract.>
+@xbullet<The attribute_designator is Read (resp. Write), and @i<T> is
+a limited type extension, and the attribute Read (resp Write) is
+available for the parent type of @i<T> and for the types of all of the
+extension components.>
+@xbullet<The attribute_designator is Input (resp. Output), and @i<T> is
+a limited type, and the attribute Read (resp. Write) is available for @i<T>.>
+@xbullet<The attribute has been specified via an
+@fa<attribute_definition_clause>, and the @fa<attribute_definition_clause>
+is visible.
+
+A stream-oriented attribute for a subtype of a class-wide type T'Class is
+available at places where one of the following conditions is true:
+@xbullet<@i<T> is nonlimited.>
+@xbullet<The attribute has been specified via an
+@fa<attribute_definition_clause>, and the @fa<attribute_definition_clause>
+is visible.>
+
+An @fa<attribute_reference> for one of the stream attributes is illegal
+unless the attribute is available at the place of the @fa<attribute_reference>.
+
+For an @fa<attribute_definition_clause> specifying one of these attributes,
+the subtype of the Item parameter shall be the base subtype if scalar, and
+the first subtype otherwise. The same rule applies to the result of the
+Input function.
+
+!corrigendum 13.13.2(36.1/1)
+
+@dinsa
+For every subtype @i<S> of a language-defined nonlimited specific type @i<T>,
+the output generated by S'Output or S'Write shall be readable by S'Input or
+S'Read, respectively. This rule applies across partitions if the implementation
+conforms to the Distributed Systems Annex.
+@dinst
+@i<@s8<Implementation Permissions>>@hr
+The number of calls performed by the predefined implementation of the stream-
+oriented attributes on the Read and Write operations of the stream type is
+unspecified. An implementation may take advantage of this permission to perform
+internal buffering. However, all the calls on the Read and Write operations of
+the stream type needed to implement an explicit invocation of a stream-oriented
+attribute must take place before this invocation returns. An explicit
+invocation is one appearing explicitly in the program text, possibly through a
+generic instantiation (see 12.3).
+
 !appendix
 
 !section 13.13.1
@@ -384,7 +589,7 @@
 
 4 - The definition of the profiles of the predefined S'Read, S'Write, S'Input
 and S'Read given in RM95 13.13.2 uses the notation "T italic" for the type of
-the Item parameter.  AI95-00145 explains that:
+the Item parameter. AI95-00145 explains that:
 
 "The italicized T shown in the definitions of predefined operators means:
 
@@ -401,7 +606,7 @@
 base subtype if scalar, and the first subtype otherwise."
 
 There is a problem because these definitions don't coincide in the case of
-constrained array types.  Consider:
+constrained array types. Consider:
 
         type T is new String (1 .. 10);
 
@@ -433,7 +638,7 @@
 attribute_definition_clause were removed?
 
 A possible model is to say that an attribute_definition_clause changes the
-body of the Read attribute, but not its profile.  It's as if the predefined
+body of the Read attribute, but not its profile. It's as if the predefined
 Read was just a wrapper calling the user-specified subprogram.
 
 5 - AI95-00108 states (in the !discussion section) that "for untagged derived
@@ -441,19 +646,19 @@
 attributes."
 
 This doesn't seem clear if the derived type includes a known discriminant
-part.  Consider:
+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.  It would seem that
+Clearly Parent'Write writes two discriminant values. It would seem that
 Child'Write should only write one discriminant value, which contradicts the
 simple inheritance rule given in the AI.
 
 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 RM95 doesn't seem
+the components in positional aggregate order. However, the RM95 doesn't seem
 to specify what happens when exceptions are raised by the calls to the Read
-attribute for the components.  Consider for example the following type
+attribute for the components. Consider for example the following type
 declarations:
 
         type T1 is range ...;
@@ -471,7 +676,7 @@
         ...
         R'Read (..., X);
 
-Assume that an exception is raised by T2'Read.  Is the discriminant X.D1
+Assume that an exception is raised by T2'Read. Is the discriminant X.D1
 modified?  That would be unpleasant if there were components depending on
 this discriminant!
 
@@ -485,12 +690,12 @@
                         C2 : T2;
                 end record;
 
-Assume that an exception is raised by T2'Read.  Is the component X.C1
+Assume that an exception is raised by T2'Read. Is the component X.C1
 modified?
 
 It would seem that we should stick to the notion that discriminants are only
-modified by an assignment of entire objects.  This probably requires an
-intermediate object in the case of discriminated types.  However, it would
+modified by an assignment of entire objects. This probably requires an
+intermediate object in the case of discriminated types. However, it would
 seem quite expensive to require the creation of such an intermediate object
 for types that don't have discriminants.
 
@@ -533,27 +738,27 @@
 Subject: 	Re: Updated AIs
 
 AI 195 does not address an issue that we have confronted
-recently relating to stream attributes.  It is very difficult
+recently relating to stream attributes. It is very difficult
 to specify stream attributes for a limited private type, if
-you require them to be specified in the visible part.  In general,
+you require them to be specified in the visible part. In general,
 you may not specify a "representation" attribute until after
-a type is fully defined.  But if you also have to specify stream
+a type is fully defined. But if you also have to specify stream
 attributes in the visible part to make them usable, then you
 have a contradiction.
 
-There seem to be two solutions.  One
+There seem to be two solutions. One
 is to allow stream attributes to be specified before the
-type is fully defined.  The other is to allow them to be specified
+type is fully defined. The other is to allow them to be specified
 in the private part.
 
 I suppose another option is to have some
 kind of "incomplete" stream attribute specification,
 such as "for Lim_Type'Read use <>;" in the visible part,
-and then complete the definition in the private part.  This is
+and then complete the definition in the private part. This is
 rampant invention, of course, but it solves another problem.
 Types like Exception_Occurrence are required to have stream attributes,
 but not have any other primitive operations declared in the
-visible part.  However stream attributes can only be defined
+visible part. However stream attributes can only be defined
 in terms of some "normal" subprogram, which must necessarily also
 be visible at the point of the stream attribute definition.
 Another contradiction...
@@ -571,19 +776,19 @@
 From: 	Pascal Leroy
 Sent: 	Monday, March 01, 1999 4:14 AM
 
-> There seem to be two solutions.  One
+> There seem to be two solutions. One
 > is to allow stream attributes to be specified before the
-> type is fully defined.  The other is to allow them to be specified
+> type is fully defined. The other is to allow them to be specified
 > in the private part.
 
-I hate to open private parts.  In our compiler, this is a real nightmare (we
+I hate to open private parts. In our compiler, this is a real nightmare (we
 have to do that for pragma Convention, and that's already a big pain in the
 neck).
 
 So my preference would be to allow the specification of stream attributes
-before the type is fully defined.  Remember that we already have an AI that
-says that 13.1(10) does not apply to stream attributes.  This would just be
-another oddity with stream-oriented attributes.  (In fact I believe the
+before the type is fully defined. Remember that we already have an AI that
+says that 13.1(10) does not apply to stream attributes. This would just be
+another oddity with stream-oriented attributes. (In fact I believe the
 stream-oriented attributes should not be considered a representation item,
 since they do not affect the physical representation of the type; they should
 be "something else", with much more relaxed rules; but we are not going to
@@ -592,7 +797,7 @@
 > I suppose another option is to have some
 > kind of "incomplete" stream attribute specification,
 > such as "for Lim_Type'Read use <>;" in the visible part,
-> and then complete the definition in the private part.  This is
+> and then complete the definition in the private part. This is
 > rampant invention, of course, but it solves another problem.
 
 This would have been a nice idea in '93, but at this point I think the
@@ -600,7 +805,7 @@
 
 > Types like Exception_Occurrence are required to have stream attributes,
 > but not have any other primitive operations declared in the
-> visible part.  However stream attributes can only be defined
+> visible part. However stream attributes can only be defined
 > in terms of some "normal" subprogram, which must necessarily also
 > be visible at the point of the stream attribute definition.
 > Another contradiction...
@@ -616,19 +821,19 @@
 From: 	Tucker Taft
 Sent: 	Monday, March 01, 1999 8:18 AM
 
-> > There seem to be two solutions.  One
+> > There seem to be two solutions. One
 > > is to allow stream attributes to be specified before the
-> > type is fully defined.  The other is to allow them to be specified
+> > type is fully defined. The other is to allow them to be specified
 > > in the private part.
 >
-> I hate to open private parts.  In our compiler, this is a real nightmare (we
+> I hate to open private parts. In our compiler, this is a real nightmare (we
 > have to do that for pragma Convention, and that's already a big pain in the
 > neck).
 >
 > So my preference would be to allow the specification of stream attributes
-> before the type is fully defined.  Remember that we already have an AI that
-> says that 13.1(10) does not apply to stream attributes.  This would just be
-> another oddity with stream-oriented attributes.  (In fact I believe the
+> before the type is fully defined. Remember that we already have an AI that
+> says that 13.1(10) does not apply to stream attributes. This would just be
+> another oddity with stream-oriented attributes. (In fact I believe the
 > stream-oriented attributes should not be considered a representation item,
 > since they do not affect the physical representation of the type; they should
 > be "something else", with much more relaxed rules; but we are not going to
@@ -642,7 +847,7 @@
 > > I suppose another option is to have some
 > > kind of "incomplete" stream attribute specification,
 > > such as "for Lim_Type'Read use <>;" in the visible part,
-> > and then complete the definition in the private part.  This is
+> > and then complete the definition in the private part. This is
 > > rampant invention, of course, but it solves another problem.
 >
 > This would have been a nice idea in '93, but at this point I think the
@@ -650,7 +855,7 @@
 >
 > > Types like Exception_Occurrence are required to have stream attributes,
 > > but not have any other primitive operations declared in the
-> > visible part.  However stream attributes can only be defined
+> > visible part. However stream attributes can only be defined
 > > in terms of some "normal" subprogram, which must necessarily also
 > > be visible at the point of the stream attribute definition.
 > > Another contradiction...
@@ -713,7 +918,7 @@
 Sent: Friday, August  3, 2001 3:47 AM
 
 I am looking at the rules for streaming of limited types in TC1 (specifically in
-DR 0040), and it seems to me that they are not quite correct.  (We never seem to
+DR 0040), and it seems to me that they are not quite correct. (We never seem to
 get streams right, no matter how hard or how often we try.)
 
 In 13.13.2(9/1), a section pertaining to Read and Write, we have:
@@ -732,7 +937,7 @@
 
 I understand that for Read and Write, these rules ensure that the attribute is
 either (1) not callable or (2) complete in the sense that it deals with all the
-components, including the limited ones.  However, the rules don't seem to work
+components, including the limited ones. However, the rules don't seem to work
 well for Input and Output.
 
 Consider the following example:
@@ -750,16 +955,16 @@
     T2'Output (...); -- Legal?
 
 13.13.2(36/1) seems to say that the reference to T2'Output is legal because
-T1'Output was specified.  13.13.2(9/1) is not applicable because the attribute
+T1'Output was specified. 13.13.2(9/1) is not applicable because the attribute
 in question is not Read or Write, so apparently the type extension is legal.
 
-One is left wondering what T2'Output does at execution.  Its default
+One is left wondering what T2'Output does at execution. Its default
 implementation is supposed to write the discriminants and then call T2'Write and
-P'Write.  But in this instance there is no T2'Write and no P'Write, so we have a
-problem.  At any rate, the existence of T1'Output is totally irrelevant, since
+P'Write. But in this instance there is no T2'Write and no P'Write, so we have a
+problem. At any rate, the existence of T1'Output is totally irrelevant, since
 T2'Output is never defined in terms of T1'Output.
 
-It seems that 13.13.2(36/1) needs revision.  For Input and Output, a reference
+It seems that 13.13.2(36/1) needs revision. For Input and Output, a reference
 should be legal iff Read or Write, resp., have been specified for some ancestor.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent