CVS difference for ais/ai-00195.txt

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

--- ais/ai-00195.txt	1999/03/13 01:36:22	1.9
+++ ais/ai-00195.txt	1999/09/23 18:39:39	1.10
@@ -1,4 +1,4 @@
-!standard 13.13.1 (00)                                99-03-12  AI95-00195/04
+!standard 13.13.1 (00)                                99-09-23  AI95-00195/05
 !class binding interpretation 98-03-27
 !status work item 98-04-04
 !status received 98-03-27
@@ -7,13 +7,15 @@
 !priority High
 !difficulty Hard
 !subject Streams
-!summary 99-03-12
 
+!summary
+
 1 - When the predefined Input attribute creates an object, this object
 undergoes default initialization and finalization.
 
-2 - In determining whether a stream-oriented attribute has been specified for
-a limited type, the normal visibility rules are applied to the
+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.
 
@@ -23,7 +25,7 @@
 00108.)
 
 4 - In the profiles of the stream-oriented attributes, the notation
-"italicized T" refers to the base type for a scalar type, and to the first
+"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,
@@ -47,8 +49,9 @@
 
 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.  However, all the calls to Read and Write needed to
-implement a top-level invocation of a stream-oriented attribute must take
+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.
 
 10 - The predefined stream-oriented attributes for a scalar type shall only
@@ -59,7 +62,7 @@
 11 - In an attribute_definition_clause for a stream-oriented attribute, the
 name shall not denote an abstract subprogram.
 
-!question 98-04-04
+!question
 
 1 - RM95 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,
@@ -142,15 +145,15 @@
 11 - In an attribute_definition_clause for a stream attribute, is it legal to
 give a name that denotes an abstract subprogram? (no)
 
-!recommendation 98-04-04
+!recommendation
 
-See summary.
+(See summary.)
 
-!wording 98-04-04
+!wording
 
-See summary.
+(See summary.)
 
-!discussion 99-03-12
+!discussion
 
 1 - It seems logical to make Input follow as closely as possible the semantics
 of code that could be written by a user, so the implementation of S'Input
@@ -176,6 +179,7 @@
         package P is
            type T is limited private;
         private
+           type T is new Boolean;
            procedure Read (Stream : ...; Item : out T);
            for T'Read use Read;
         end P;
@@ -340,7 +344,7 @@
 stated in RM95 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 pervert implementation of these operations,
+for the stream type by writing a perverse implementation of these operations,
 but it seems that performance should have precedence: for the predefined
 implementation of String'Write, requiring a call to Ada.Streams.Write for
 each character would be a big performance hit, with no real benefits.
@@ -365,21 +369,21 @@
 extra negative value," as explained in RM95 3.5.4(9).
 
 Based on this rule (and assuming typical hardware), an implementation might
-choose an 8-, 16-, 32- or 64-bit base type for T.
+choose an 8-, 16-, 32- or 64-bit base subtype for T.
 
 RM95 13.13.2(17) advise the implementation to "use the smaller number of
 stream elements needed to represent all values in the base range of the scalar
 type" when reading or writing values of type T.
 
 Clearly this is a portability issue: if two implementation use (as is typical)
-8-bit stream elements, but have different rules for selecting base types, the
+8-bit stream elements, but have different rules for selecting base subtypes, the
 number of elements read to or written from a stream will differ.  This makes
 it very hard to write stream operations that comply with an externally
 defined format.
 
 In the above case, it would seem reasonable to read or write only the minimum
 number of stream elements necessary to represent the range 1 .. 10.  This
-would remove the dependency on the base type selection, and make it easier to
+would remove the dependency on the base subtype selection, and make it easier to
 write portable stream operations.  (There is still the possibility that
 different implementations would choose different sizes for stream elements,
 but that doesn't seem to happen in practice on typical hardware.)
@@ -426,7 +430,7 @@
 attribute_definition_clause only to reject all calls doesn't seem to do any
 good.  That's why the first option was preferred.
 
-!appendix 98-03-27
+!appendix
 
 !section 13.13.1
 !subject Various issues with the stream-oriented attributes

Questions? Ask the ACAA Technical Agent