CVS difference for ai12s/ai12-0020-1.txt

Differences between 1.12 and version 1.13
Log of other versions for file ai12s/ai12-0020-1.txt

--- ai12s/ai12-0020-1.txt	2018/07/06 05:25:13	1.12
+++ ai12s/ai12-0020-1.txt	2018/10/15 23:57:45	1.13
@@ -1,4 +1,4 @@
-!standard 4.10(0)                                     18-06-14    AI12-0020-1/04
+!standard 4.10(0)                                     18-10-14   AI12-0020-1/05
 !standard 3.5(27.1/2)
 !standard 3.5(55.1/5)
 !standard 3.5(55.2/5)
@@ -14,9 +14,10 @@
 !subject 'Image for all types
 !summary
 
-Define T'Put_Image for all types, and redefine T'Image, T'Wide_Image,
-and T'Wide_Wide_Image in terms of it. (This provides a default image for
-objects of all types.)
+Define T'Put_Image for all types, and define (or redefine, for scalars)
+T'Image, T'Wide_Image, and T'Wide_Wide_Image in terms of it.
+This provides a default Image attribute for all types as well
+as the allowing (in effect) user-specified Image attributes for types.
 
 !problem
 
@@ -28,65 +29,59 @@
 T'Image is defined for (almost) all types (including class-wide types).
 Ditto for T'Wide_Image and T'Wide_Wide_Image.
 
-All of these are defined in terms of T'Put_Image, a stream-like attribute
-with the specification:
+All of these are defined in terms of a procedure T'Put_Image, an
+attribute with the specification:
 
-   S'Put_Image
-       (Arg : T; Stream : access Counted_Stream'Class);
+   procedure T'Put_Image
+       (Arg : T; Stream : not null access Ada.Streams.Root_Stream_Type'Class);
 
-Like streams, this routine can be specified for any type to give
+Like stream attributes, this attribute can be specified for any type to give
 a user-defined image for that type. Also like streams, this routine is
 inherited by derived types (although it is always available, unlike
-stream attributes).
+stream attributes). So to get the effect of a user-specified Image attribute,
+one specifies a user-defined Put_Image procedure.
 
-Default implementation:
-   For scalars - unchanged.
+The default implementation of S'Put_Image writes out to the stream
+(using Wide_Wide_String'Write) an image of the value of Arg; that is,
+a Wide_Wide_String representing the value in display form.
+
+That Wide_Wide_String value is determined (approximately) as follows:
+   For scalars - same image that Wide_Wide_Image has always generated
+     since it was introduced in Ada95.
    For access types -
-     Integer value displayed as a hex digits in square brackets,
+     Integer value displayed as a hex digits preceded by an '@',
      except null displayed as "NULL". Number of hex digits determined
-     by size of access type. For example, "[FF0012AC]".
+     by size of access type. For example, "@FF0012AC".
    For task types -
       Undiscriminated: "(TASK <task_id_image>)"
       Discriminated: "(TASK <task_id_image> with D1 => 123, D2 => 456)"
    For protected types -
-      Nothing special. Same as any record type.
+      Same as for a record type except that the opening left parenthesis
+      is followed by "PROTECTED with", as in
+      "(PROTECTED with F1 =>  123, F2 =>  456)".
       Protected_Obj'Image is a protected function (this matters, for example,
       for locking).
    For all other composite types:
-      Named aggregate syntax is used; only white space is a single blank 
-      after "," and both before and after "=>". This can result in double 
-      blanks in some cases, as in
-         "(Field =>  123)"
-      where the second blank comes from the image of the component value.
-      For all record types:
-         Record component names in upper case (same as existing rule for
-           'Image of enumeration values).
-         Record component ordering follows positional aggregate rules.
+      Named aggregate syntax is used, as in
+        "(F1 => 123, F2 => 456)".
+      Null records displayed as "(NULL RECORD)".
       For type extensions:
          By default we treat a type extension the same as any other record type.
-         This may involve (in corner cases) having multiple components with
-         the same component name, but that's ok because the order disambiguates.
          However, if an ancestor type has a user-defined Put_Image attribute,
          we use extension aggregate syntax, as in
              "(<parent part image> with C1 => 123, C2 => 4.5)" .
-  
-         It would have been more regular to always use extension-aggregate 
-         syntax but the result would be less readable, especially for deep 
-         hierarchies.
       For class-wide types, the image obtained from the specific
-         type is prefixed with the Wide_Wide_Expanded_Name of the tag
+         type is prefixed with the name of the tag
          and a "'", yielding qualified expression syntax, as in
-            "My_Pkg.My_Tagged_Type'(ABC => True, DEF => 123.45)"
+            "My_Pkg.My_Tagged_Type'(ABC => True, DEF => 123.45)".
       For array types:
          Array index names generated via image.
          Null arrays displayed as
-            "(1 .. 0 => <>)" or "(1 .. 0 => (1 .. 10 => <>))" 
-         Null records displayed as "(NULL RECORD)".
+            "(1 .. 0 => <>)" or "(1 .. 0 => (1 .. 10 => <>))"
          There is no special treatment for string types.
 
 !wording
 
-
 We are going to define Image and related attributes for (almost) all types
 and objects, so we begin by deleting the existing definitions which are
 specific to scalars.
@@ -113,15 +108,16 @@
 
    Static Semantics
 
-    For every subtype S of a non-universal type T, the following
-    type-related operational attributes are defined:
+      For every subtype S of a non-universal type T, the following
+      type-related operational attributes are defined:
 
       S'Put_Image
-         S'Put_Image denotes a procedure with the following specification:
-            S'Put_Image
-               (Arg : T; Stream : access Counted_Stream'Class);
- 	    
-      The default implementation of S'Put_Image writes out
+        S'Put_Image denotes a procedure with the following specification:
+           S'Put_Image
+             (Arg    : T;
+              Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+
+      The default implementation of S'Put_Image writes
       (using Wide_Wide_String'Write)
       an image of the value of Arg; that is, a Wide_Wide_String
       representing the value in display form.
@@ -139,117 +135,57 @@
 
       S'Wide_Wide_Image
 
-         S'Wide_Wide_Image denotes a function with the following specification:
-            function S'Wide_Wide_Image (Arg : S'Base)
-              return Wide_Wide_String
-
-        The implementation of S'Wide_Wide_Image calls S'Put_Image
-        (which will typically write a sequence of Wide_Wide_Character values
-	out to a stream) and then returns the result of reading the contents
-        of that stream; the lower bound of that result is 1.
-        More specifically, it is equivalent to
-	
-           function T'Wide_Wide_Image (Arg : T) return Wide_Wide_String is
-              Local_Stream : aliased
-                Ada.Streams.Counted_Streams.Unbounded.Unbounded_Stream;
-                -- see 13.13.1
+      S'Wide_Wide_Image denotes a function with the following specification:
+        function S'Wide_Wide_Image (Arg : S'Base) return Wide_Wide_String
 
-              Elements_Per_Char : constant :=
-                Wide_Wide_Character'Stream_Size / Stream_Element'Size;
-                -- typically 4
-           begin
-              T'Put_Image (Arg, Local_Stream'Access);
-              return Result :
-                Wide_Wide_String (1 ..
-                 (Element_Count (Local_Stream) + (Elements_Per_Char - 1))
-                 / Elements_Per_Char)
-              do
-                 Wide_Wide_String'Read (Result, Local_Stream'Access);
-              end return;
-           end;
+      The implementation of S'Wide_Wide_Image calls S'Put_Image
+      (which will typically write a sequence of Wide_Wide_Character values
+      out to a stream) and then returns the result of reading the contents
+      of that stream via Wide_Wide_String'Read; the lower bound of that
+      result is 1.
 
-         except that if the value of T'Max_Image_Elements (see below)
-         is not -1 then the variable Local_Stream is instead declared as
-              Local_Stream : aliased
-                Ada.Streams.Counted_Streams.Unbounded.Unbounded_Stream
-                  (Max_Elements => T'Max_Image_Elements);
-                -- see 13.13.1
-         .
-
       S'Wide_Image
-         S'Wide_Image denotes a function with the following specification: 
+         S'Wide_Image denotes a function with the following specification:
          function S'Wide_Image (Arg : T) return Wide_String
 
          The function returns an image of the value of Arg as a Wide_String.
          The lower bound of the result is one. The image has the same sequence
-	 of graphic characters as defined for S'Wide_Wide_Image if all the
-	 graphic characters are defined in Wide_Character; otherwise, the
-	 sequence of characters is implementation defined (but no shorter
-	 than that of S'Wide_Wide_Image for the same value of Arg). 
+         of graphic characters as defined for S'Wide_Wide_Image if all the
+         graphic characters are defined in Wide_Character; otherwise, the
+         sequence of characters is implementation defined (but no shorter
+         than that of S'Wide_Wide_Image for the same value of Arg).
 
      S'Image
-        S'Image denotes a function with the following specification: 
+        S'Image denotes a function with the following specification:
            function S'Image(Arg : S'Base) return String
 
         The function returns an image of the value of Arg as a String.
         The lower bound of the result is one. The image has the same
-	sequence of graphic characters as that defined for S'Wide_Wide_Image
-	if all the graphic characters are defined in Character; otherwise,
-	the sequence of characters is implementation defined (but no shorter
-	than that of S'Wide_Wide_Image for the same value of Arg). 
-
-     S'Max_Image_Elements
-        S'Max_Image_Elements yields the value of T's Max_Image_Elements
-        aspect. The type of both the aspect and the attribute is
-        Ada.Streams.Stream_Offset.
-        The Max_Image_Elements attribute may be specified for any
-        type T either via an attribute_definition_clause, via
-        an aspect_specification specifying the Put_Image aspect of the type,
-	or (in the case of a derived type) via inheritance.
-        If specified, the aspect_definition shall be a static expression in
-	the range -1 .. Ada.Streams.Stream_Element_Offset'Last.
-	If no value for the aspect is specified, then value of the aspect
-        is determined by any Default_Max_Image_Elements
-        pragmas (described below) which are applicable to the compilation unit
-	in which T's full declaration occurs, if any such pragmas exist.
-	If no value for the aspect is specified and no such pragma exists,
-	then the value of the aspect is -1.
-
-   Syntax
-
-    The form of a Default_Max_Image_Elements pragma is
-    is follows:
-
-      pragma Default_Max_Image_Elements (*stream_offset_*expression);
-
-   Name Resolution Rules
-
-    The expected type for a stream_offset_expression is
-    Streams.Stream_Offset.
-
-   Legality Rules
-
-    Default_Max_Image_Elements is a configuration pragma, and shall
-    not be used other than as a configuration pragma.
-    The *stream_offset_*expression shall be a static expressions in
-    the range -1 .. Streams.Stream_Element_Offset'Last.
- 
-    If more than one Default_Max_Image_Elements
-    pragma applies to a given compilation unit, then they shall all
-    specify equal (static) Stream_Element_Offset values.
-
-   Static semantics
-
-    [A Default_Max_Image_Elements pragma participates in
-    determining the Max_Image_Elements aspect(s) of zero or more
-    types as described above.]
+        sequence of graphic characters as that defined for S'Wide_Wide_Image
+        if all the graphic characters are defined in Character; otherwise,
+        the sequence of characters is implementation defined (but no shorter
+        than that of S'Wide_Wide_Image for the same value of Arg).
+
+    The following *restriction_parameter*_identifier is language defined:
+       Max_Image_Length.
+         Specifies the maximum length for a Wide_Wide_Image attribute result
+         whose evaluation does not result in a bounded error. [AARM note:
+         Image and Wide_Image are defined in terms of Wide_Wide_Image, so
+         this restriction also applies to evaluations of those attributes.]
+         In the bounded error case, Program_Error or Constraint_Error may
+         be propagated from a Wide_Wide_Image attribute call or an
+         implementation defined value may be returned.
+
+    If a Max_Image_Length restriction applies
+    to any compilation unit in the partition, then for any subtype S
+    S'Wide_Wide_Image shall be implemented without any dynamic allocation.
 
 
     The behavior of the default implementation of S'Put_Image depends
     on the class of T. For an elementary type, the implementation is
     equivalent to
        procedure Put_Image
-         (Arg : Scalar_Type; Stream : access Counted_Stream'Class)
+         (Arg : Scalar_Type; Stream : access Ada.Streams.Root_Stream_Type'Class)
        is
        begin
           Wide_Wide_String'Write (<described below>, Stream)
@@ -257,9 +193,9 @@
     where the Wide_Wide_String value written out to the stream is
     defined as follows:
 
-       AARM Discussion: In earlier versions of Ada, Image and related 
+       AARM Discussion: In earlier versions of Ada, Image and related
        attributes were defined only for scalar types. The definition of these
-       attributes is now textually very different, but it is intended
+       attributes is now very different, but it is intended
        that there should be no change in the behavior of existing
        programs as a result of these changes. End AARM Discussion.
 
@@ -332,15 +268,16 @@
        For an access type (named or anonymous), the image written out depends
        on whether the value is null. If it is null, then the image is "NULL".
        Otherwise the image is a sequence of uppercase hexadecimal digits
-       representing the value enclosed in square brackets, as in "[FF0012AC]".
+       representing the value preceded by an at-sign, as in "@FF0012AC".
        The number of hexadecimal digits will be the same for all non-null
        values of any one access type.
 
-   [In general, the default implementation of T'Put_Image for a composite
-   type will involve some sequence of calls to Wide_Wide_String'Write
-   and calls to the Put_Image procedures of component types and, in the
-   case of an array type, index types. The Wide_Wide_String'Write calls
-   may pass in either literal values (e.g., "(", ")", "'(", " => ", or ", "),
+   [AARM note: In general, the default implementation of T'Put_Image for
+   a composite type will involve some sequence of calls to
+   Wide_Wide_String'Write and calls to the Put_Image procedures of component
+   types and, in the case of an array type, index types.
+   The Wide_Wide_String'Write calls may pass in either literal values
+   (e.g., "(", ")", "'(", " => ", or ", "),
    or other things (such as component names for record values, task_id
    images for tasks, or the Wide_Wide_Expanded_Name of the tag in the
    class-wide case).]
@@ -350,23 +287,25 @@
    array aggregate syntax using calls to the Put_Image procedures of
    the index type(s) and the element type to generate images for values
    of those type.
-   This might generate an image such as
+
+
+   [AARM note: This might generate an image such as
     ( 1 => ( 1 => ( 123 => True,  124 => False)
              2 => ( 123 => False,  124 => False)),
       2 => ( 1 => ( 123 => True,  124 => True),
              2 => ( 123 => True,  124 => False)))
-   except with each sequence of spaces and line breaks replaced
-   with a single space (with two spaces in the case of the spaces
-   between a comma and an integer literal).
+   although perhaps with different white space and/or line breaking.]
+
    The case of a null array is handled specially, using ranges for
    index bounds and "<>" as a syntactic component-value placeholder.
-   This might generate an image such as
-   "( 1 ..  3 => ( 1 ..  0 => ( 1 .. 5 => <>))), where the use of "<>"
-   (among other things) indicates that the array argument is a null array.
+
+   [AARM Note: This might generate an image such as
+   "( 1 ..  3 => ( 1 ..  0 => ( 1 .. 5 => <>)))", where the use of "<>"
+   (among other things) indicates that the array argument is a null array.]
 
-   The the order in which components are written for
+   The order in which components are written for
    a composite type is the same canonical order in
-   which, for example, components of a composite type T are written out
+   which components of a composite type T are written out
    by the default implementation of T'Write. [This is also the
    order that is used in determining the meaning of a positional aggregate
    of type T.]
@@ -374,24 +313,26 @@
    For a class-wide type, the default implementation of T'Put_Image
    generates an image based on qualified expression syntax.
    Wide_Wide_String'Write is called with Wide_Wide_Expanded_Name of Arg'Tag.
-   Next the literal "'(" is written out.
    Then Corresponding_Specific_Type'Put_Image is called. [At the
    implementation level this will typically require a dispatching call.]
-   Finally a right parenthesis is written. This might generate an image
-   such as
+
+   [AARM Note: This might generate an image such as
       "SOME_PACKAGE.SOME_TAGGED_TYPE'(COMPONENT_1 =>  123, COMPONENT_2 =>  456)"
-   .
+   . The parentheses in this case are generated by the call to
+   Some_Tagged_Type'Put_Image.]
 
    For a (specific) type extension, the default implementation of T'Put_Image
-   depends  on whether there exists a noninterface ancestor of T (other than
+   depends on whether there exists a noninterface ancestor of T (other than
    T itself) for which the Put_Image aspect has been [explicitly] specified.
    If so, then T'Put image will generate an image based on extension aggregate
    syntax where the ancestor type of the extension aggregate is the
    nearest ancestor type whose Put_Aspect has been specified.
-   [This might generate an image such as
+
+  [AARM note: This might generate an image such as
    "(This Text Was User-Generated with C1 =>  123, C2 =>  456)"
    where the "This Text was User-Generated" portion of the text was
    generated by the call to the user-specified Put_Image routine.]
+
    If no such ancestor exists, then the default implementation of T'Put_Image
    is the same as described below for an untagged record type.
 
@@ -399,13 +340,18 @@
    a type extension which meets the criteria described in the previous
    paragraph, or a protected type, the default implementation of
    T'Put_Image generates an image based on (named, not positional) record
-   aggregate syntax. Component names are displayed in upper case,
-   following the rules for the image of an enumeration value. Component
-   values are displayed via calls to the component type's Put_Image
-   procedure. This might generate an image such as
-   "(FOO => ( 1 => 'c',  2 => 'a',  3 => 't'), BAR => TRUE)".
+   aggregate syntax (except that for a protected type, the initial left
+   parenthesis is followed by "PROTECTED with ").
+   Component names are displayed in upper case, following the rules for the
+   image of an enumeration value. Component values are displayed via calls to
+   the component type's Put_Image procedure.
+
+   [AARM note:  This might generate an image such as
+   "(FOO => ( 1 => 'c',  2 => 'a',  3 => 't'), BAR => TRUE)".]
+
    The image written out for a record having no components (including
-   any interface type) is "(NULL RECORD)".
+   any interface type) is "(NULL RECORD)". The image written out for a
+   componentless protected type is "(PROTECTED NULL RECORD)".
    In the case of a protected type T, a call to the default implementation
    of T'Put_Image begins only one protected (read-only) action.
 
@@ -417,7 +363,7 @@
    because it does not need a write-lock, not because it returns a
    meaningful result.]
 
-   [TBH - Note that the assertion in the following example should succeed:
+   [TBH - The assertion in the following example should succeed:
       type T1 (D1, D2 : Positive) is record ... end record; -- untagged
       type T2 (D : Positive) is new T1 (D1 => D, D2 => D);
       X : T2 (D => 123) := ... ;
@@ -426,11 +372,16 @@
    For an undiscriminated task type, the default implementation of T'Put_Image
    generates an image of the form "(TASK <task_id_image>)"
    where <task_id_image> is the result obtained by calling
-   Ada.Task_Identification.Image with the id of the given task.
+   Ada.Task_Identification.Image with the id of the given task
+   and then passing that String to Characters.Conversions.To_Wide_Wide_String.
+
    For a discriminated task type, the default implementation of T'Put_Image
    also includes discriminant values, as in
    "(TASK <task_id_image> with D1 =>  123, D2 =>  456)".
 
+   [AARM note: If T is an unchecked union type, then the default
+   implementation of T'Put_Image will raise Program_Error.]
+
 For a prefix X that denotes an object of a non-universal type T, the following
 attributes are defined:
    X'Wide_Wide_Image
@@ -443,105 +394,61 @@
       X'Image denotes the result of calling function S'Image with Arg being X,
       where S is the nominal subtype of X.
 
-====
+   Implementation Permissions
 
-Add after 13.13.1(9) (the end of the static semantics section):
-
-   The following related units are also declared.
-
-      package Ada.Streams.Counted_Streams is
-         type Counted_Stream is abstract new Root_Stream_Type with private;
-
-         function Element_Count (Stream : Counted_Stream)
-           return Stream_Element_Count is abstract;
-      end Ada.Streams.Counted_Streams;
-
-       package Ada.Streams.Counted_Streams.Unbounded is
-          type Unbounded_Stream is new Counted_Stream with private
-          with Default_Initial_Condition =>
-            Element_Count (Unbounded_Stream) = 0;
-
-          overriding
-          procedure Read (
-	     Stream : in out Unbounded_Stream;
-             Item   : out Stream_Element_Array;
-             Last   : out Stream_Element_Offset)
-             with Post =>
-               Element_Count (Stream) =
-               Element_Count (Stream)'Old - Item (Item'First .. Last)'Length;
-          overriding
-          procedure Write (
-             Stream : in out Unbounded_Stream;
-             Item   : in Stream_Element_Array)
-             with Post =>
-               Element_Count (Stream) =
-               Element_Count (Stream)'Old + Item'Length;
-          overriding
-          function Element_Count (Stream : Unbounded_Stream)
-             return Stream_Element_Count;
-       end Ada.Streams.Counted_Streams.Unbounded;
-
-       package Ada.Streams.Counted_Streams.Bounded is
-         -- same as Unbounded except for the discriminant
-
-         type Bounded_Stream (Max_Elements : Stream_Element_Count)
-           is new Counted_Stream with private
-           with Default_Initial_Condition =>
-             Element_Count (Unbounded_Stream) = 0;
-
-          overriding
-          procedure Read (
-	     Stream : in out Bounded_Stream;
-             Item   : out Stream_Element_Array;
-             Last   : out Stream_Element_Offset)
-             with Post =>
-               Element_Count (Stream) =
-               Element_Count (Stream)'Old - Item (Item'First .. Last)'Length;
-          overriding
-          procedure Write (
-             Stream : in out Bounded_Stream;
-             Item   : in Stream_Element_Array)
-             with Pre =>
-               Element_Count (Stream) + Item'Length <= Stream.Max_Elements
-               or else (raise Constraint_Error)
-             with Post =>
-               Element_Count (Stream) =
-               Element_Count (Stream)'Old + Item'Length;
-          overriding
-          function Element_Count (Stream : Bounded_Stream)
-             return Stream_Element_Count
-             with Post => Element_Count'Result <= Stream.Max_Elements;
-       end Ada.Streams.Counted_Streams.Bounded;
+   An implementation may transform the image generated by the default
+   implementation of S'Put_Image for a composite subtype S in the
+   following ways:
+
+     - If S is a composite subtype, the leading character of the image of
+       a component value or index value is a space, and the immediately
+       preceding character is an open parenthesis, then the space may be
+       omitted. The same transformation is also permitted if the leading
+       character of the component image is a space (in which case one of
+       the two spaces may be omitted).
+       [AARM note: This means that it is permitted to
+       generate "(1 => 123, 2 => 456)" instead of "( 1 =>  123,  2 =>  456)".]
+
+     - If S is an array subtype, the low bound of the array in each dimension
+       equals the low bound of the corresponding index subtype, and the
+       array value is not a null array value, then positional array
+       aggregate syntax may be used.
+       [AARM note: This means that it is permitted to
+       generate "(TRUE, TRUE, FALSE)" instead of
+       "( 1 => TRUE,  2 => TRUE,  3 => FALSE)" if the low bound of the
+       index subtype is one.]
+
+     - If S is an array subtype and the given value can be displayed using
+       named array aggregate syntax where some discrete_choice_list identifies
+       more than one index value by identifying a sequence of one or more
+       ranges and values separated by vertical bars, then this
+       image may be generated instead; this may involve the reordering of
+       component values.
+       [AARM note: This means that it is permitted to
+       generate "( 1 ..  2 |  5 => TRUE,  3 ..  4 => FALSE)" instead of
+       "( 1 => TRUE,  2 => TRUE,  3 => FALSE,  4 => FALSE,  5 => TRUE)".]
+
+     - Similarly, if S is a record subtype (or a discriminated type) and the
+       given value can be displayed using named component association syntax
+       where the length of some component_choice_list is greater than one,
+       then this image may be generated instead; this may involve the
+       reordering of component values.
+       [AARM note: This means that it is permitted to generate
+       "(F1 | F2 => TRUE)" instead of "(F1 => TRUE, F2 => TRUE)".]
 
-The Element_Count functions return the number of stream elements
-that are available for reading in the given stream.
-
-====
-
-Add after 13.13.1(9.1/1):
-
-Implementation Advice
-
-Bounded_Stream objects should be implemented without implicit pointers or
-dynamic allocation.
-
-  AARM Reason: The Counted_Streams.Bounded package is provided in order to
-  make available an alternative to the Counted_Streams.Unbounded
-  package which gives more predictable memory usage.
-
 !discussion
 
 
-The expected (although not required) implementation of the package 
+The expected (although not required) implementation of the package
 Ada.Streams.Counted_Streams.Unbounded involves dynamic storage allocation of some
 kind, perhaps accompanied with uses of controlled types.
 
-For some applications with high integrity/reliability requirements, those 
-requirements (more specifically, requirements about predictable memory 
+For some applications with high integrity/reliability requirements, those
+requirements (more specifically, requirements about predictable memory
 utilization) might preclude use of this package.
 
-Nonetheless, we would like such applications to be able to use T'Image for a 
-non-scalar type T without having to override the default implementation of 
+Nonetheless, we would like such applications to be able to use T'Image for a
+non-scalar type T without having to override the default implementation of
 T'Put_Image.
 
 That is the motivation for introducing
@@ -553,23 +460,23 @@
        T'Max_Image_Elements and the default implementation
        of T'Put_Image .
 
-An application can specify T'Max_Image_Elements either explicitly or via a 
+An application can specify T'Max_Image_Elements either explicitly or via a
 Default_Max_Image_Elements configuration pragma. Having done that, the default
-implementation of T'Put_Image will reference Counted_Streams.Bounded instead 
+implementation of T'Put_Image will reference Counted_Streams.Bounded instead
 of Counted_Streams.Unbounded.
 
 This will achieve the desired goal.
 
-The cost is that the burden is on the user to choose a "good" value for 
+The cost is that the burden is on the user to choose a "good" value for
 T'Max_Image_Elements. If the value is too small, then a call to T'Put_Image
-may fail; if the value is too big, then the storage requirements of a call 
+may fail; if the value is too big, then the storage requirements of a call
 to T'Put_Image may be unnecessarily large.
 
 ----
 
 Put_Image is user-specifiable; Wide_Wide_Image is not.
 
-One could imagine instead allowing user-specified Wide_Wide_Image attributes 
+One could imagine instead allowing user-specified Wide_Wide_Image attributes
 and not bothering to define User_Put_Image at all.
 
 The drawback of this approach is that it would could introduce, at least for
@@ -578,7 +485,7 @@
 Given
     type T is record F1, F2, F3 : Integer; end record;
 
-the default implementation of T'Wide_Wide_Image could have been defined to be 
+the default implementation of T'Wide_Wide_Image could have been defined to be
 something like
 
       return "(F1 => " &
@@ -591,7 +498,7 @@
 
 but that's a lot of concatenation; the situation for arrays would be even worse.
 
-Furthermore, the two Ada.Streams.Counted_Streams packages (Bounded and 
+Furthermore, the two Ada.Streams.Counted_Streams packages (Bounded and
 Unbounded) seem like they will be useful in their own right.
 
 ----
@@ -685,7 +592,7 @@
       Wide_Wide_String'Write (", C3 => ", Stream);
       <arg>.C3'Put (Stream)
       Wide_Wide_String'Write (")", Stream);
-   end Put_Image;      
+   end Put_Image;
 
 A variant part introduces a corresponding case statement.
 
@@ -705,20 +612,60 @@
            Wide_Wide_String'Write (" => ", Stream);
            <arg>(Idx)'Put (Stream);
            if Idx /= <arg>'Last then
-             Wide_Wide_String'Write (", ", Stream);              
+             Wide_Wide_String'Write (", ", Stream);
            end if;
          end if;
       end loop;
       Wide_Wide_String'Write (")", Stream);
-   end;      
+   end;
 
 Other types are handled similarly; just calls to Wide_Wide_String'Write mixed
 with Put_Image calls for components. Note that the implementation of
-T'Class'Put_Image will involve a dispatching call to the Put_Image of the 
-corresponding specific type (after writing out the Wide_Wide_Expanded_Name of 
+T'Class'Put_Image will involve a dispatching call to the Put_Image of the
+corresponding specific type (after writing out the Wide_Wide_Expanded_Name of
 the tag and a "'"), so that requires a new entry in the dispatch table for each
 tagged type.
 
+=====
+
+The following is intended as a reference implementation of
+S'Wide_Wide_Image, assuming the definition of Ada.Streams.FIFO_Streams
+and related units as described in AI12-0293-1.
+
+     function T'Wide_Wide_Image (Arg : T) return Wide_Wide_String is
+        Local_Stream : aliased
+          Ada.Streams.FIFO_Streams.Unbounded.Stream_Type;
+          -- see 13.13.1
+
+        Elements_Per_Char : constant :=
+          Wide_Wide_Character'Stream_Size / Stream_Element'Size;
+          -- typically 4
+     begin
+        T'Put_Image (Arg, Local_Stream'Access);
+        return Result :
+          Wide_Wide_String (1 ..
+           (Element_Count (Local_Stream) + (Elements_Per_Char - 1))
+           / Elements_Per_Char)
+        do
+           Wide_Wide_String'Read (Result, Local_Stream'Access);
+        end return;
+     end;
+
+except that if one or more Max_Image_Length restrictions
+applies to any compilation unit included in the
+partition, then the variable Local_Stream is instead declared as
+
+     Local_Stream : aliased
+       Ada.Streams.FIFO_Streams.Bounded.Stream_Type
+         (Max_Elements =>
+         <the smallest specified Max_Image_Length restriction value>
+         * Elements_Per_Char);
+       -- see 13.13.1
+
+In this case, exceeding the Max_Elements buffer capacity is a
+bounded error. Constraint_Error or Program_Error may be propagated,
+or an implementation defined result may be returned.
+
 !ACATS test
 
 ** TBD.
@@ -1208,11 +1155,11 @@
 >>      dependent. For example, the image for any value of such
 >>      a type might be "<>". Or it might be something more useful.
 >>      As mentioned earlier, users can override.
-> 
+>
 > You have two #3s here. :-)
-> 
-> For a task, one could imagine using the task id somehow. (At least, 
-> that was my first thought.) Not completely useful (especially for 
+>
+> For a task, one could imagine using the task id somehow. (At least,
+> that was my first thought.) Not completely useful (especially for
 > 'Value), but it would clearly allow telling tasks apart and would be useful
 > for debugging.
 
@@ -1224,8 +1171,8 @@
 
 I've omitted in this reply all of your subsequent 'Value-related comments.
 
-> For access values, one could mandate using the image of the associated 
-> Integer_Address in, say square brackets. (That would be familiar to 
+> For access values, one could mandate using the image of the associated
+> Integer_Address in, say square brackets. (That would be familiar to
 > anyone used to an Intel assembler.)
 
 Fair enough, although if we are going to require something then I'd rather see
@@ -1248,10 +1195,10 @@
 >>      special for protected records.
 >>
 >>      In the no-components case, image is "(null record)".
-> 
-> One needs to specify the case of the component names in this 
-> aggregate. I'd expect the assertion to fail, because those names will 
-> probably be all UPPER CASE or all lower case -- but never mixed case. 
+>
+> One needs to specify the case of the component names in this
+> aggregate. I'd expect the assertion to fail, because those names will
+> probably be all UPPER CASE or all lower case -- but never mixed case.
 > (Most likely, copy the enumeration rule.)
 
 Good point.
@@ -1266,11 +1213,11 @@
 >>      (as noted earlier) it can lead to a lot of redundant text in
 >>      some cases. If we do that, then we'd need consistent syntax
 >>      for the null array case (single- and multi-dimensional).
-> 
+>
 > You seem to have answered your own question here. And I tend to agree.
-> 'Image of large data structures is never going to be very useful (what 
-> do you do with 20 pages of output), so it probably makes sense to just 
-> use the syntax that provides the most information and least chance of 
+> 'Image of large data structures is never going to be very useful (what
+> do you do with 20 pages of output), so it probably makes sense to just
+> use the syntax that provides the most information and least chance of
 > getting it wrong.
 
 It's worth noting that when we display an index value, we of course use the
@@ -1284,10 +1231,10 @@
 >>      or like
 >>        "(X =>  123, Y =>  456)" -- note the two additional spaces
 >>      ? See the Assert pragma in item #3 above.
-> 
-> Not sure here. It would be a pain to try to eliminate the leading 
-> blanks for numeric 'Image, so I probably would say leave the extra 
-> blanks. (Or maybe, skip putting a blank after "=>", as it will still 
+>
+> Not sure here. It would be a pain to try to eliminate the leading
+> blanks for numeric 'Image, so I probably would say leave the extra
+> blanks. (Or maybe, skip putting a blank after "=>", as it will still
 > be syntactically correct either way.) One can always user-define it if you
 > need it perfect.
 
@@ -1328,7 +1275,7 @@
 
 More thoughts on this.
 
-> It's worth noting that when we display an index value, we of course 
+> It's worth noting that when we display an index value, we of course
 > use the Image attribute of the index type.
 
 "the Image attribute" => "the appropriate image attribute".
@@ -1337,7 +1284,7 @@
 evaluating Some_Array'Wide_Wide_Image, then we want to use
 Index_Type'Wide_Wide_Image (as opposed to Index_Type'Image).
 
-> I agree, Task_Identification.Image of the task id is what we want for 
+> I agree, Task_Identification.Image of the task id is what we want for
 > tasks.
 
 Discriminated task types should display the discriminant values somehow.
@@ -1352,7 +1299,7 @@
 Or perhaps we drop the word "task", but then the parens look odd in the
 undiscriminated task case. Do we drop them?
 
->  Nothing special for protected records. 
+>  Nothing special for protected records.
 
 Presumably Some_Protected_Object'Image behaves like a call to a protected
 function with respect to locking.
@@ -1383,7 +1330,7 @@
 Sent: Friday, January 25, 2018  2:56 PM
 
 > I'm also wondering, and I know we discussed it live but I don't see any
-> mention of that in your mail Steve: What about 'Value ? I think we said that 
+> mention of that in your mail Steve: What about 'Value ? I think we said that
 >'Value won't >be implemented for complex types, but it would be better to
 > state it clearly I guess.
 
@@ -1408,10 +1355,10 @@
 
 ...
 > Note that no changes involving 'Value are proposed in this AI.
-> As Raphael points out, it would probably be good to mention this 
+> As Raphael points out, it would probably be good to mention this
 > explicitly (i.e., to talk about what we are not talking about).
-> 
-> I've omitted in this reply all of your subsequent 'Value-related 
+>
+> I've omitted in this reply all of your subsequent 'Value-related
 > comments.
 
 My point of mentioning 'Value in my comments is that I want the possibility
@@ -1425,11 +1372,11 @@
 I think that is fair game to talk about whether or not the suggested format
 could support 'Value (or similar user-written routines).
 
-> > For access values, one could mandate using the image of the 
-> > associated Integer_Address in, say square brackets. (That would be 
+> > For access values, one could mandate using the image of the
+> > associated Integer_Address in, say square brackets. (That would be
 > > familiar to anyone used to an Intel assembler.)
-> 
-> Fair enough, although if we are going to require something then I'd 
+>
+> Fair enough, although if we are going to require something then I'd
 > rather see the address displayed in hex.
 
 The only issue with that is that we don't have a hex image routine anywhere.
@@ -1444,19 +1391,19 @@
 > >>      or like
 > >>        "(X =>  123, Y =>  456)" -- note the two additional spaces
 > >>      ? See the Assert pragma in item #3 above.
-> > 
-> > Not sure here. It would be a pain to try to eliminate the leading 
-> > blanks for numeric 'Image, so I probably would say leave the extra 
-> > blanks. (Or maybe, skip putting a blank after "=>", as it will still 
-> > be syntactically correct either way.) One can always user-define it 
+> >
+> > Not sure here. It would be a pain to try to eliminate the leading
+> > blanks for numeric 'Image, so I probably would say leave the extra
+> > blanks. (Or maybe, skip putting a blank after "=>", as it will still
+> > be syntactically correct either way.) One can always user-define it
 > > if you need it perfect.
-> 
-> Changing the behavior of numeric 'Image would be grossly incompatible; 
+>
+> Changing the behavior of numeric 'Image would be grossly incompatible;
 > that seems out of the question to me.
 
 I agree, but I was not suggesting that.
- 
-> I was thinking more about looking for a leading space on a component 
+
+> I was thinking more about looking for a leading space on a component
 > image and conditionally preceding it with either a "=> " or a "=>"
 > when generating the image of an enclosing composite object.
 
@@ -1469,28 +1416,28 @@
 debugging anyway, perfection not required.
 
 > ===
-> 
+>
 > I was thinking some more about the
 > Image/Wide_Image/Wide_Wide_Image rules.
-> 
-> 90% of the time, all that anyone is interested in is the Image 
-> attribute and it is somewhat clunky to have to specify the 
+>
+> 90% of the time, all that anyone is interested in is the Image
+> attribute and it is somewhat clunky to have to specify the
 > Wide_Wide_Image aspect (or even mention Wide_Wide_String at all).
-> 
-> But we want to retain consistency between the 3 image attributes; we 
-> don't want, for example, to allow users to explicitly specify Image 
+>
+> But we want to retain consistency between the 3 image attributes; we
+> don't want, for example, to allow users to explicitly specify Image
 > and Wide_Image aspects for one type.
-> 
-> I originally proposed one solution: only Wide_Wide_Image is 
+>
+> I originally proposed one solution: only Wide_Wide_Image is
 > specifiable.
-> 
-> How about, instead, allowing any *one* of the three aspects Image, 
+>
+> How about, instead, allowing any *one* of the three aspects Image,
 > Wide_Image, Wide_Wide_Image to be specified?
-> Whatever aspect is specified determines the behavior of all three 
-> attributes. [Alternatively, we could say that only Image is 
-> specifiable but the specified value can be a function returning any of 
-> the three predefined string types; there are advantages to this 
-> approach - we don't have to worry about defining what happens in a 
+> Whatever aspect is specified determines the behavior of all three
+> attributes. [Alternatively, we could say that only Image is
+> specifiable but the specified value can be a function returning any of
+> the three predefined string types; there are advantages to this
+> approach - we don't have to worry about defining what happens in a
 > case like
 >       type T1 is ... with Wide_Image => ... ;
 >       type T2 is new T1 with Image => ... ; ].
@@ -1498,26 +1445,26 @@
 Whatever the rule is, it can allow specifying only one. In this latter
 Bairdian case, I'd expect the second one to totally override all three.
 I'll leave the exact rule to you.
-  
+
 ****************************************************************
 
 From: Steve Baird
 Sent: Friday, January 25, 2018  3:29 PM
 
 > So, if there is a syntax
-> that would work for 'Value, and one that would not work for 'Value, I 
+> that would work for 'Value, and one that would not work for 'Value, I
 > strongly lean toward the one that would allow 'Value.
 
 I agree.
 
->>> For access values, one could mandate using the image of the 
->>> associated Integer_Address in, say square brackets. (That would be 
+>>> For access values, one could mandate using the image of the
+>>> associated Integer_Address in, say square brackets. (That would be
 >>> familiar to anyone used to an Intel assembler.)
 >>>
 >>
->> Fair enough, although if we are going to require something then I'd 
+>> Fair enough, although if we are going to require something then I'd
 >> rather see the address displayed in hex.
-> 
+>
 > The only issue with that is that we don't have a hex image routine anywhere.
 > Integer_Address'Image is well-defined.
 
@@ -1525,9 +1472,9 @@
 bad. I'd rather leave it implementation dependent than to require
 decimal-format display for addresses. My first choice is requiring hex.
 
-> My suggestion was simply to always generate "=>" (with no trailing 
-> space), as that is lexically and syntactically correct, and it avoids 
-> the double spacing. Otherwise, just don't worry about that -- this is 
+> My suggestion was simply to always generate "=>" (with no trailing
+> space), as that is lexically and syntactically correct, and it avoids
+> the double spacing. Otherwise, just don't worry about that -- this is
 > mainly for debugging anyway, perfection not required.
 
 In a situation where one space would be ideal, I'd rather see two spaces than
@@ -1536,7 +1483,7 @@
 in array aggregates (and these can appear in at least 3 different contexts -
 after a left paren, a comma, or a "..").
 
-> Whatever the rule is, it can allow specifying only one. In this latter 
+> Whatever the rule is, it can allow specifying only one. In this latter
 > Bairdian case, I'd expect the second one to totally override all three.
 
 Agreed.
@@ -1547,19 +1494,19 @@
 Sent: Friday, January 25, 2018  9:51 PM
 
 ...
-> >>> For access values, one could mandate using the image of the 
-> >>> associated Integer_Address in, say square brackets. (That would be 
+> >>> For access values, one could mandate using the image of the
+> >>> associated Integer_Address in, say square brackets. (That would be
 > >>> familiar to anyone used to an Intel assembler.)
 > >>>
 > >>
-> >> Fair enough, although if we are going to require something then I'd 
+> >> Fair enough, although if we are going to require something then I'd
 > >> rather see the address displayed in hex.
-> > 
-> > The only issue with that is that we don't have a hex image routine 
+> >
+> > The only issue with that is that we don't have a hex image routine
 > > anywhere. Integer_Address'Image is well-defined.
-> > 
-> 
-> Requiring (as opposed to allowing) something that isn't very useful 
+> >
+>
+> Requiring (as opposed to allowing) something that isn't very useful
 > would be bad.
 
 On modern 32-bit machines, neither is very useful. Data point: When Janus/Ada
@@ -1605,7 +1552,7 @@
 From: Jean-Pierre Rosen
 Sent: Saturday, January 27, 2018  1:28 AM
 
-> The only issue with that is that we don't have a hex image routine 
+> The only issue with that is that we don't have a hex image routine
 > anywhere. Integer_Address'Image is well-defined.
 
 If the (hex) image uses based notation, it can be fed back to 'Value
@@ -1618,39 +1565,39 @@
 > ...
 > Discriminated task types should display the discriminant values somehow.
 > Perhaps extension-aggregate-ish syntax? Something like
-> 
+>
 >   (task <task id image> with D1 => This, D2 => that)
-> 
+>
 > and then, for consistency, undiscriminated image is
-> 
+>
 >   (task <task id image>) .
-> 
-> Or perhaps we drop the word "task", but then the parens look odd in 
+>
+> Or perhaps we drop the word "task", but then the parens look odd in
 > the undiscriminated task case. Do we drop them?
 
 I like the word "task" being there, and always using parentheses for composite
 types.
 
-> Nothing special for protected records. 
+> Nothing special for protected records.
 
 I would think you would have "(protected <id-of-some sort> with disc1 => X,
 disc2 => Y, comp1 => Z, ...)" to be consistent with tasks, and to make it
 clear that this is not your normal record.
 
-> Presumably Some_Protected_Object'Image behaves like a call to a 
+> Presumably Some_Protected_Object'Image behaves like a call to a
 > protected function with respect to locking.
-> 
+>
 >>   Named-notation syntax is probably the way to go...
 >>   If we do that, then we'd need consistent syntax
 >>   for the null array case (single- and multi-dimensional).
-> 
-> If we define syntax for null array aggregates, then we should use 
+>
+> If we define syntax for null array aggregates, then we should use
 > whatever is agreed upon. Otherwise, how about
-> 
+>
 >    "(1 .. 0 => <>)"
-> 
+>
 >    "(1 .. 3 => (1 .. 0 => <>))"
-> 
+>
 >    "(1 .. 0 => (1 .. 3 => <>))"
 > ? Or perhaps "()" instead of "<>".
 
@@ -1661,14 +1608,14 @@
 From: Steve Baird
 Sent: Wednesday, February 28, 2018  8:03 PM
 
-I still don't have real RM wording for this one, but here is a more detailed 
-outline than what we had before for this AI, incorporating feedback from the 
+I still don't have real RM wording for this one, but here is a more detailed
+outline than what we had before for this AI, incorporating feedback from the
 last meeting and subsequent discussions with Bob and Tuck. [This is the
 !proposal section of version /02 of the AI - Editor.]
 
 First, a summary of what we plan for the default (as opposed to
-user-specified) implementations of T'Image for a possibly-nonscalar type T. 
-Much of this has already been discussed, but there is some new stuff (e.g., 
+user-specified) implementations of T'Image for a possibly-nonscalar type T.
+Much of this has already been discussed, but there is some new stuff (e.g.,
 the treatment of type extensions).
 
 The completely new stuff that has not previously been discussed on the ARG
@@ -1682,7 +1629,7 @@
 From: Tucker Taft
 Sent: Thursday, March  1, 2018  6:52 AM
 
-I preferred the proposal to include the words "task ..." or "protected ..." 
+I preferred the proposal to include the words "task ..." or "protected ..."
 in the 'Image for such types.  You wrote:
 
    For task types -
@@ -1718,9 +1665,9 @@
 Sent: Thursday, March  1, 2018  9:37 PM
 
 > Earlier I had seen a proposal of approximately:
-> 
+>
 >    (task <task_id_image>) -- no discriminants
-> 
+>
 >    (task <task_id_image> with D1 => 123, D2 => 456)
 
 I think you made that proposal, so I'm pretty sure you saw it. ;-)
@@ -1729,46 +1676,46 @@
 which would make no sense without context.
 
 > and for protected types, the analogous thing:
-> 
+>
 >    (protected <protected_id_image>)  -- no discriminants or private components
 >    (protected <pid> with D1 => ... , C1 => ...) -- discriminants and/or components
 
 I agree with the "protected" part, but there is no such thing as a
-<protected_id>; protected types are just records with a predefined blob used 
-by the task supervisor. One could use the address if someone insisted on an 
-<id>, but this doesn't seem different than any other record type in that in 
-some cases you might need to display the identity. In that case, you should 
-dump the address as well as the image. So I don't think there should be any 
+<protected_id>; protected types are just records with a predefined blob used
+by the task supervisor. One could use the address if someone insisted on an
+<id>, but this doesn't seem different than any other record type in that in
+some cases you might need to display the identity. In that case, you should
+dump the address as well as the image. So I don't think there should be any
 <protected_id> here.
 
-In the case of tasks, most of them have no other components so the task id is 
+In the case of tasks, most of them have no other components so the task id is
 needed to even get an idea of the type. That's unlikely for protected objects.
-If we'd prefer consistency, I'd rather drop the id from the tasks rather than 
+If we'd prefer consistency, I'd rather drop the id from the tasks rather than
 force a non-existent thing into the protected case.
- 
-> I think these have a nice symmetry, and will reduce confusion with 
+
+> I think these have a nice symmetry, and will reduce confusion with
 > other aggregates.
-> 
-> Clearly protected objects have some kind of identity (typically some 
-> sort of internal semaphore ID), and that is something that would be of 
-> interest.  Just dumping the value of the private components would be 
+>
+> Clearly protected objects have some kind of identity (typically some
+> sort of internal semaphore ID), and that is something that would be of
+> interest.  Just dumping the value of the private components would be
 > losing significant information.
 
 I strongly disagree with this: Janus/Ada exposes none of this stuff even to
 the rest of the compiler. The compiler just sees a private type of a
-particular size. We'd have to define new task supervisor operations 
+particular size. We'd have to define new task supervisor operations
 specifically for this purpose if we needed to expose something else -- but
 the "something else" doesn't even exist. The address of the protected object
 serves to identify it in any case that is needed.
 
-I'd be surprised if other compilers differed on this. These guys - 
+I'd be surprised if other compilers differed on this. These guys -
 particularly because they have discriminants - are much more like a record
 with some special operations when accessed than a task (which is an active
 structure). Perhaps there is some mutex that the underlying OS gives an Id
 to, but that has nothing to do with Ada.
 
 The idea of a Task_Id is well-defined in Ada; there's an entire section in
-the Standard talking about it. And that defines an Image function. That's 
+the Standard talking about it. And that defines an Image function. That's
 what would appear in 'Image.
 
 Imagining a whole new mechanism (one that is nonexistent in at least some
@@ -1881,25 +1828,25 @@
 
 There is also a small !discussion section, but it discusses only a few corner
 cases; it is by no means complete. For example, the !discussion section lacks
-a rationale for why the Put_Image attribute/aspect was introduced and why 
+a rationale for why the Put_Image attribute/aspect was introduced and why
 Put_Image is user-specifiable but [Wide_[Wide_]]Image is not.
 
-Undoubtedly several rough spots remain (although Randy already caught several 
-for me in his preliminary review), but hopefully this can at least give us a 
+Undoubtedly several rough spots remain (although Randy already caught several
+for me in his preliminary review), but hopefully this can at least give us a
 preliminary version to work with.
 
-One question I have is whether the level of precision of the description of 
-the default implementations of the T'Put_Image for a composite type T is 
+One question I have is whether the level of precision of the description of
+the default implementations of the T'Put_Image for a composite type T is
 acceptable.
 
-For example, for a record type we pretty much just say that we display 
-components in the canonical order using positional aggregate syntax, 
+For example, for a record type we pretty much just say that we display
+components in the canonical order using positional aggregate syntax,
 displaying component names in upper case and calling each component type's
 Put_Image procedure to display component values. Then we give an example and
 that's about it.
 
 Given this approach, it is not clear whether these examples belong in normal
-RM text (which is how I have presented them) or as examples presented 
+RM text (which is how I have presented them) or as examples presented
 separately in an "Examples" section.
 
 Take a look at the proposed presentation and see what you think.
@@ -1916,19 +1863,19 @@
 For the record, here's a few editorial-ish things that I did when posting
 this:
 
-(1) You didn't give a !summary or a !proposal. It seemed useful to have the 
-short overview of the default images for each kind of type, so I left that 
-(hopefully I found all of the changes), following a couple introductory 
+(1) You didn't give a !summary or a !proposal. It seemed useful to have the
+short overview of the default images for each kind of type, so I left that
+(hopefully I found all of the changes), following a couple introductory
 paragraphs. The rest was dropped.
 
-(2) I moved the example "Put_Image" implementations into the !discussion; 
+(2) I moved the example "Put_Image" implementations into the !discussion;
 they seemed valuable and shouldn't get lost. (Fixing the names, of course,
 and also fixing the component names in the record case (they were all
 "C1").)
 
-(3) I changed the wording instructions to start with a capital letter. That 
-is "Delete 3.5(...", not "delete 3.5(...". Added a few missing commas into 
-those, too. The paragraph references should mention AARM paragraphs 
+(3) I changed the wording instructions to start with a capital letter. That
+is "Delete 3.5(...", not "delete 3.5(...". Added a few missing commas into
+those, too. The paragraph references should mention AARM paragraphs
 separately, but I didn't fix that yet.
 
 (4) "new section 4.10 named "Images":" should say "Add a new subclause
@@ -1952,14 +1899,14 @@
    .
 
 We aren't even allowed to use a hanging period like this in AI text, much less
-in the RM. But we don't need the extra indentation anyway, as the example 
+in the RM. But we don't need the extra indentation anyway, as the example
 should be in the example font. So this would read better as
 
    For a discriminated task type, the default implementation of T'Put_Image
    also includes discriminant values, as in
    "(TASK <task_id_image> with D1 =>  123, D2 =>  456)".
 
-We're hoping that the editor remembers to mark these examples in the example 
+We're hoping that the editor remembers to mark these examples in the example
 font, but that's pretty likely (I know him well :-).
 
 I reformatted the other examples to match, similar reasoning applies.
@@ -1970,9 +1917,9 @@
              Item   : out Stream_Element_Array;
              Last   : out Stream_Element_Offset)
 
-The recommended formatting of overriding indicators has them on a separate 
+The recommended formatting of overriding indicators has them on a separate
 line from the rest of the subprogram declaration, much like "generic". The RM
-is supposed to follow this recommended formatting, regardless of what you 
+is supposed to follow this recommended formatting, regardless of what you
 normally do in your own code. I fixed all of these declarations.
 
 ===================================
@@ -1986,8 +1933,8 @@
                 Ada.Streams.Counted_Streams.Unbounded.Unbounded_Stream
                   (Max_Elements => T'Max_Image_Elements);
 
-Isn't this case supposed to use the Bounded form of the stream? The Unbounded 
-form doesn't even have a discriminant. I'd guess that "Un" should be deleted 
+Isn't this case supposed to use the Bounded form of the stream? The Unbounded
+form doesn't even have a discriminant. I'd guess that "Un" should be deleted
 from the above text (twice).
 
 (C2)
@@ -2000,20 +1947,20 @@
     pragma applies to a given compilation unit, then they shall all
     specify equal (static) Stream_Element_Offset values.
 
-I'm not sure that we can use such a short definition of a pragma. All pragmas 
+I'm not sure that we can use such a short definition of a pragma. All pragmas
 that I can think of give a syntax definition; even List and Page do that. So I
 think we need to define the "form" of this pragma, with a Syntax portion.
 (Ugh, I know.)
 
-(C3) You probably ought to add a paragraph to the discussion describing the 
+(C3) You probably ought to add a paragraph to the discussion describing the
 model and use of Bounded_Stream. I know why it's there ('cause you told me),
 but it doesn't seem to be mentioned anywhere in the AI.
 
-(C4) You deleted all of the AARM notes along with the original definition of 
-Wide_Wide_Image, but you didn't put them back into the discussion of the 
+(C4) You deleted all of the AARM notes along with the original definition of
+Wide_Wide_Image, but you didn't put them back into the discussion of the
 default images of the various types. That seems like (relatively) important
 information about topics like Negative Zeros and rounding is getting lost.
-The Impldef information for Wide_Image and Image definitely has to move (so 
+The Impldef information for Wide_Image and Image definitely has to move (so
 the annex M.1 listing doesn't lose them). A similar thought applies to 55.b/5.
 
 (C5) Under the image of arrays, you have:
@@ -2022,9 +1969,9 @@
        "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 => False,
 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => ( 123 => True,  124 => False)))"
 
-This is too long for a line in the RM. It will get folded somehow, and that 
+This is too long for a line in the RM. It will get folded somehow, and that
 would probably give an incorrect interpretation of the actual result. (I see
-this e-mail editor folded it!) I don't know what the appropriate answer is 
+this e-mail editor folded it!) I don't know what the appropriate answer is
 here, but this can't be in the RM as written; we need an alternative that fits
 in one line or additional wording to explain the extra line breaks.
 
@@ -2036,46 +1983,46 @@
 This is wrong, unless you mean to disallow using 'Image on a universal integer
 object. And if you meant to do that, you need to explain why and explain the
 (significant) incompatibility in the !discussion section.
-Moreover, you've reintroduced the object bug fixed in AI12-0225-1. We don't 
+Moreover, you've reintroduced the object bug fixed in AI12-0225-1. We don't
 want X to have to denote an object!
 
 Otherwise, this should read:
 
-For a prefix X of a type other than universal_real or universal_fixed, the 
+For a prefix X of a type other than universal_real or universal_fixed, the
 following attributes are defined:
 
-Perhaps you need to make a similar change to Put_Image; there's no problem 
-defining it for the (dynamic) universal_integer type (that is the largest 
+Perhaps you need to make a similar change to Put_Image; there's no problem
+defining it for the (dynamic) universal_integer type (that is the largest
 signed integer type). You can't *redefine* that attribute, but that shouldn't
 matter.
 
-(C7) We've previously discussed in passing the need for Ada to have 
+(C7) We've previously discussed in passing the need for Ada to have
 "marshalling" streams. (Claw has had those since 1999 - we needed them to
 pack/unpack binary clipboard and registry contents - items that have to be
 read/written in a single operation.) You're actually adding them sort of by
 the back door. I have to wonder if they ought to have a bit more visibility
-and if the names are right -- these packages fulfill an important need 
+and if the names are right -- these packages fulfill an important need
 having nothing to do with Image.
 
-We have a "Clear" operation to discard the contents - that seems useful in 
+We have a "Clear" operation to discard the contents - that seems useful in
 more general usage, even if Put_Image will never need it.
 
 We also had an initial size discriminant for the unbounded form. Not as sure
-if that's useful, or if there should be some Reserve_Capacity operation for 
+if that's useful, or if there should be some Reserve_Capacity operation for
 the unbounded form. (We did it that way for the containers.)
 
 (C99) "If a protected type T has protected subcomponents, then the default
-implementation of T'Put_Image will probably violate the 
+implementation of T'Put_Image will probably violate the
 no-potentially-blocking-ops-during-a-protected-action rule.
 Do we want any sort of legality rules relating to this?
 In evaluating any possible rules relating to this scenario, keep in mind the
-case of a protected type declared in the body of a generic unit with a 
+case of a protected type declared in the body of a generic unit with a
 subcomponent of a formal limited private type whose corresponding actual type,
 for some particular instance of the generic, is a protected type."
 
 I guess it couldn't be a Steve Baird AI without at least one such case.
 *Everyone* is worried about taking the image of a protected object declared in
-a generic body with a component of a formal limited private type. Happens 
+a generic body with a component of a formal limited private type. Happens
 every other day! ;-)
 
 ***************************************************************
@@ -2084,28 +2031,28 @@
 Sent: Wednesday, June 6, 2018  8:05 PM
 
 >> Here is a first attempt at !wording for this AI.
-> 
-> For the record, here's a few editorial-ish things that I did when 
+>
+> For the record, here's a few editorial-ish things that I did when
 > posting
 > this:
 
 Thanks. It all sounds good.
 
 > ===================================
-> 
+>
 > And here are a few minor comments:
-> 
+>
 > (C1)
 >           except that if the value of T'Max_Image_Elements (see below)
 >           is not -1 then the variable Local_Stream is instead declared as
 >                Local_Stream : aliased
 >                  Ada.Streams.Counted_Streams.Unbounded.Unbounded_Stream
 >                    (Max_Elements => T'Max_Image_Elements);
-> 
-> Isn't this case supposed to use the Bounded form of the stream? The 
-> Unbounded form doesn't even have a discriminant. I'd guess that "Un" 
+>
+> Isn't this case supposed to use the Bounded form of the stream? The
+> Unbounded form doesn't even have a discriminant. I'd guess that "Un"
 > should be deleted from the above text (twice).
-> 
+>
 
 Good catch. Your fix is indeed what I intended.
 
@@ -2118,89 +2065,89 @@
 >      as a configuration pragma. If more than one Default_Max_Image_Elements
 >      pragma applies to a given compilation unit, then they shall all
 >      specify equal (static) Stream_Element_Offset values.
-> 
-> I'm not sure that we can use such a short definition of a pragma. All 
-> pragmas that I can think of give a syntax definition; even List and 
-> Page do that. So I think we need to define the "form" of this pragma, 
+>
+> I'm not sure that we can use such a short definition of a pragma. All
+> pragmas that I can think of give a syntax definition; even List and
+> Page do that. So I think we need to define the "form" of this pragma,
 > with a Syntax portion. (Ugh, I know.)
 
 Really? I guess I can't argue that this one is even simpler than pragma Page,
 so ok.
 
-> (C3) You probably ought to add a paragraph to the discussion 
-> describing the model and use of Bounded_Stream. I know why it's there 
+> (C3) You probably ought to add a paragraph to the discussion
+> describing the model and use of Bounded_Stream. I know why it's there
 > ('cause you told me), but it doesn't seem to be mentioned anywhere in the AI.
 
 It's there for the same reason that we provide the bounded containers.
 
-> (C4) You deleted all of the AARM notes along with the original 
-> definition of Wide_Wide_Image, but you didn't put them back into the 
-> discussion of the default images of the various types. That seems like 
-> (relatively) important information about topics like Negative Zeros and 
+> (C4) You deleted all of the AARM notes along with the original
+> definition of Wide_Wide_Image, but you didn't put them back into the
+> discussion of the default images of the various types. That seems like
+> (relatively) important information about topics like Negative Zeros and
 > rounding is getting lost.
-> The Impldef information for Wide_Image and Image definitely has to 
-> move (so the annex M.1 listing doesn't lose them). A similar thought 
+> The Impldef information for Wide_Image and Image definitely has to
+> move (so the annex M.1 listing doesn't lose them). A similar thought
 > applies to 55.b/5.
 
 Good point.
 
 > (C5) Under the image of arrays, you have:
-> 
+>
 >     This might generate an image such as
->         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 => 
+>         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 =>
 > False,
-> 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => ( 123 
+> 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => ( 123
 > => True,  124 => False)))"
-> 
-> This is too long for a line in the RM. It will get folded somehow, and 
-> that would probably give an incorrect interpretation of the actual 
-> result. (I see this e-mail editor folded it!) I don't know what the 
-> appropriate answer is here, but this can't be in the RM as written; we 
+>
+> This is too long for a line in the RM. It will get folded somehow, and
+> that would probably give an incorrect interpretation of the actual
+> result. (I see this e-mail editor folded it!) I don't know what the
+> appropriate answer is here, but this can't be in the RM as written; we
 > need an alternative that fits in one line or additional wording to explain
 > the extra line breaks.
 
 Like you, I'm not sure what to do here. Some thought is required.
 
 > (C6)
-> 
-> For a prefix X that denotes an object of a non-universal type T, the 
+>
+> For a prefix X that denotes an object of a non-universal type T, the
 > following attributes are defined:
-> 
-> This is wrong, unless you mean to disallow using 'Image on a universal 
-> integer object. And if you meant to do that, you need to explain why 
+>
+> This is wrong, unless you mean to disallow using 'Image on a universal
+> integer object. And if you meant to do that, you need to explain why
 > and explain the (significant) incompatibility in the !discussion section.
-> Moreover, you've reintroduced the object bug fixed in AI12-0225-1. We 
+> Moreover, you've reintroduced the object bug fixed in AI12-0225-1. We
 > don't want X to have to denote an object!
-> 
+>
 > Otherwise, this should read:
-> 
-> For a prefix X of a type other than universal_real or universal_fixed, 
+>
+> For a prefix X of a type other than universal_real or universal_fixed,
 > the following attributes are defined:
 
 Sounds good.
 
-> Perhaps you need to make a similar change to Put_Image; there's no 
-> problem defining it for the (dynamic) universal_integer type (that is 
-> the largest signed integer type). You can't *redefine* that attribute, 
+> Perhaps you need to make a similar change to Put_Image; there's no
+> problem defining it for the (dynamic) universal_integer type (that is
+> the largest signed integer type). You can't *redefine* that attribute,
 > but that shouldn't matter.
 
 Yes, both occurrences of "non-universal" in the wording I proposed should be
 similarly updated as you suggest.
 
-> (C7) We've previously discussed in passing the need for Ada to have 
-> "marshalling" streams. (Claw has had those since 1999 - we needed them 
-> to pack/unpack binary clipboard and registry contents - items that 
-> have to be read/written in a single operation.) You're actually adding 
-> them sort of by the back door. I have to wonder if they ought to have 
-> a bit more visibility and if the names are right -- these packages 
+> (C7) We've previously discussed in passing the need for Ada to have
+> "marshalling" streams. (Claw has had those since 1999 - we needed them
+> to pack/unpack binary clipboard and registry contents - items that
+> have to be read/written in a single operation.) You're actually adding
+> them sort of by the back door. I have to wonder if they ought to have
+> a bit more visibility and if the names are right -- these packages
 > fulfill an important need having nothing to do with Image.
-> 
-> We have a "Clear" operation to discard the contents - that seems 
+>
+> We have a "Clear" operation to discard the contents - that seems
 > useful in more general usage, even if Put_Image will never need it.
-> 
-> We also had an initial size discriminant for the unbounded form. Not 
-> as sure if that's useful, or if there should be some Reserve_Capacity 
-> operation for the unbounded form. (We did it that way for the 
+>
+> We also had an initial size discriminant for the unbounded form. Not
+> as sure if that's useful, or if there should be some Reserve_Capacity
+> operation for the unbounded form. (We did it that way for the
 > containers.)
 
 Good questions.
@@ -2216,12 +2163,12 @@
 Sent: Thursday, June 7, 2018  5:12 PM
 
 ...
-> > (C3) You probably ought to add a paragraph to the discussion 
-> > describing the model and use of Bounded_Stream. I know why it's 
-> > there ('cause you told me), but it doesn't seem to be mentioned 
+> > (C3) You probably ought to add a paragraph to the discussion
+> > describing the model and use of Bounded_Stream. I know why it's
+> > there ('cause you told me), but it doesn't seem to be mentioned
 > > anywhere in
 the AI.
-> 
+>
 > It's there for the same reason that we provide the bounded containers.
 
 Sure, but we need to describe that, and how to avoid the dynamic allocation
@@ -2229,15 +2176,15 @@
 
 Something like:
 
-We provide the Bounded_Stream package in order that 'Image can be used in 
+We provide the Bounded_Stream package in order that 'Image can be used in
 environments where dynamic allocation is banned. In such an environment, the
 user ought to <<do this, that, and the other - put a real description
-here>>. That forced the compiler to use Bounded_Stream rather than 
+here>>. That forced the compiler to use Bounded_Stream rather than
 here>>Stream to implement 'Image, <<more descriptive text>>.
 
 ...
 > > (C5) Under the image of arrays, you have:
-> > 
+> >
 > >     This might generate an image such as
 > >         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 =>
 > ( 123 =>
@@ -2245,50 +2192,50 @@
 > > 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),
 > 2 => ( 123
 > > => True,  124 => False)))"
-> > 
-> > This is too long for a line in the RM. It will get folded somehow, 
-> > and that would probably give an incorrect interpretation of the 
-> > actual result. (I see this e-mail editor folded it!) I don't know 
-> > what the appropriate answer is here, but this can't be in the RM as 
-> > written; we need an alternative that fits in one line or additional 
+> >
+> > This is too long for a line in the RM. It will get folded somehow,
+> > and that would probably give an incorrect interpretation of the
+> > actual result. (I see this e-mail editor folded it!) I don't know
+> > what the appropriate answer is here, but this can't be in the RM as
+> > written; we need an alternative that fits in one line or additional
 > > wording to explain the extra line breaks.
-> > 
-> 
+> >
+>
 > Like you, I'm not sure what to do here. Some thought is required.
 
-Given that, I'm going to leave fixing all of seven of these issues to you (I'm 
-over budget as it is). Please revise the AI with the changes (if I haven't 
+Given that, I'm going to leave fixing all of seven of these issues to you (I'm
+over budget as it is). Please revise the AI with the changes (if I haven't
 posted the corrected version yet when you get back from your trip, ask me for
 it first).
 
 ...
-> > (C7) We've previously discussed in passing the need for Ada to have 
-> > "marshalling" streams. (Claw has had those since 1999 - we needed 
-> > them to pack/unpack binary clipboard and registry contents - items 
-> > that have to be read/written in a single operation.) You're actually 
-> > adding them sort of by the back door. I have to wonder if they ought 
-> > to have a bit more visibility and if the names are right -- these 
+> > (C7) We've previously discussed in passing the need for Ada to have
+> > "marshalling" streams. (Claw has had those since 1999 - we needed
+> > them to pack/unpack binary clipboard and registry contents - items
+> > that have to be read/written in a single operation.) You're actually
+> > adding them sort of by the back door. I have to wonder if they ought
+> > to have a bit more visibility and if the names are right -- these
 > > packages fulfill an important need having nothing to do with Image.
 
-If we had more time, I would have suggested splitting them out and treating 
+If we had more time, I would have suggested splitting them out and treating
 them separately. But at this point, that probably would make more work than be
 helpful.
 
-> > We have a "Clear" operation to discard the contents - that seems 
+> > We have a "Clear" operation to discard the contents - that seems
 > > useful in more general usage, even if Put_Image will never need it.
-> > 
-> > We also had an initial size discriminant for the unbounded form. Not 
-> > as sure if that's useful, or if there should be some 
-> > Reserve_Capacity operation for the unbounded form. (We did it that 
+> >
+> > We also had an initial size discriminant for the unbounded form. Not
+> > as sure if that's useful, or if there should be some
+> > Reserve_Capacity operation for the unbounded form. (We did it that
 > > way for the
 > > containers.)
-> 
+>
 > Good questions.
-> 
-> I'd say don't make any changes along these lines in the !wording yet 
+>
+> I'd say don't make any changes along these lines in the !wording yet
 > and we can hash it out when we discuss the AI.
 
-Yes, this is fine. I just wanted to raise the issue as these packages are 
+Yes, this is fine. I just wanted to raise the issue as these packages are
 generally useful beyond just implementing Put_Image. We ought to think about
 those more general uses, even if we don't end up making any changes for that.
 
@@ -2299,8 +2246,8 @@
 
 Some comments Steve:
 
-“The default implementation of S'Put_Image writes out (using 
-Wide_Wide_String'Write and or Wide_Wide_String'Output)” – maybe “and/or” or 
+“The default implementation of S'Put_Image writes out (using
+Wide_Wide_String'Write and or Wide_Wide_String'Output)” – maybe “and/or” or
 just “or”?
 
 “The Max_Image_Elements attribute may be specified for any type type T either
@@ -2322,12 +2269,12 @@
       "( 1 ..  3 => ( 1 ..  0 => ( 1 .. 5 => <>)))
 , where the use of "<>" (among other things) indicates that the array
 argument is a null array.” – if 248-1 is approved, we could use “null array”
-rather than “<>”.  “<>” tends to indicate “something” (even if we’re not 
-saying exactly what here) rather than “nothing”, e.g. in 214-1 “<>” 
+rather than “<>”.  “<>” tends to indicate “something” (even if we’re not
+saying exactly what here) rather than “nothing”, e.g. in 214-1 “<>”
 indicates NOT null (pointer).
 
 “For a (specific) type extension, the default implementation of T'Put_Image
-depends on whether there exists a non-interface ancestor” – I like the 
+depends on whether there exists a non-interface ancestor” – I like the
 use of English English, but I’m sure Gary would object to the hyphen.
 
 “In the case of a protected type T, a call to the default implementation
@@ -2340,7 +2287,7 @@
 From: Randy Brukardt
 Sent: Monday, June 11, 2018  9:34 PM
 
-...        
+...
   zero), a decimal point, S'Digits–1 (see 3.5.8) digits after the
   decimal point (but one if S'Digits is one), an upper case E, the sign
   of the exponent (either + or –),” – what are the – meant to be?
@@ -2356,26 +2303,26 @@
 Sent: Wednesday, June 13, 2018  5:46 PM
 
 >> (C2)
->>      Pragma Default_Max_Image_Elements is a configuration pragma 
+>>      Pragma Default_Max_Image_Elements is a configuration pragma
 >> which
 >>      takes a single argument, a static expression of type
 >>      Ada.Streams.Stream_Offset in the range
 >>      -1 .. Ada.Streams.Stream_Element_Offset'Last.
 >>      Pragma Default_Max_Image_Elements shall not be used other than
->>      as a configuration pragma. If more than one 
+>>      as a configuration pragma. If more than one
 >> Default_Max_Image_Elements
 >>      pragma applies to a given compilation unit, then they shall all
 >>      specify equal (static) Stream_Element_Offset values.
 >>
->> I'm not sure that we can use such a short definition of a pragma. All 
->> pragmas that I can think of give a syntax definition; even List and 
->> Page do that. So I think we need to define the "form" of this pragma, 
+>> I'm not sure that we can use such a short definition of a pragma. All
+>> pragmas that I can think of give a syntax definition; even List and
+>> Page do that. So I think we need to define the "form" of this pragma,
 >> with a Syntax portion. (Ugh, I know.)
 >>
-> 
-> Really? I guess I can't argue that this one is even simpler than 
+>
+> Really? I guess I can't argue that this one is even simpler than
 > pragma Page, so ok.
-> 
+>
 Ok, use J.15.12 (pragma Relative_Deadline) or D.2.2 (pragma
 Priority_Specific_Dispatching) as templates (in particular, with respect to
 fonts) and replace the above with
@@ -2408,16 +2355,16 @@
        determining the Max_Image_Elements aspect(s) of zero or more
        types as described above.]
 
->> (C3) You probably ought to add a paragraph to the discussion 
->> describing the model and use of Bounded_Stream. I know why it's there 
->> ('cause you told me), but it doesn't seem to be mentioned anywhere in 
+>> (C3) You probably ought to add a paragraph to the discussion
+>> describing the model and use of Bounded_Stream. I know why it's there
+>> ('cause you told me), but it doesn't seem to be mentioned anywhere in
 >> the AI.
 >>
-> 
+>
 > It's there for the same reason that we provide the bounded containers.
-> 
+>
 
-Note that the only text along these lines that we have for bounded containers 
+Note that the only text along these lines that we have for bounded containers
 is A.18's AARM text
     "Similarly, a separate bounded version is provided in order to give
     more predictable memory usage."
@@ -2434,18 +2381,18 @@
     package which gives more predictable memory usage.]
 
 
->> (C4) You deleted all of the AARM notes along with the original 
->> definition of Wide_Wide_Image, but you didn't put them back into the 
->> discussion of the default images of the various types. That seems 
->> like (relatively) important information about topics like Negative 
+>> (C4) You deleted all of the AARM notes along with the original
+>> definition of Wide_Wide_Image, but you didn't put them back into the
+>> discussion of the default images of the various types. That seems
+>> like (relatively) important information about topics like Negative
 >> Zeros and rounding is getting lost.
->> The Impldef information for Wide_Image and Image definitely has to 
->> move (so the annex M.1 listing doesn't lose them). A similar thought 
+>> The Impldef information for Wide_Image and Image definitely has to
+>> move (so the annex M.1 listing doesn't lose them). A similar thought
 >> applies to 55.b/5.
 >>
-> 
+>
 > Good point.
-> 
+>
 
 In the current RM, we have
 
@@ -2514,23 +2461,23 @@
 >> (C5) Under the image of arrays, you have:
 >>
 >>     This might generate an image such as
->>         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 => 
+>>         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 =>
 >> False,
->> 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => ( 
+>> 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => (
 >> 123 => True,  124 => False)))"
 >>
->> This is too long for a line in the RM. It will get folded somehow, 
->> and that would probably give an incorrect interpretation of the 
+>> This is too long for a line in the RM. It will get folded somehow,
+>> and that would probably give an incorrect interpretation of the
 >> actual result.
 >> (I see
->> this e-mail editor folded it!) I don't know what the appropriate 
->> answer is here, but this can't be in the RM as written; we need an 
->> alternative that fits in one line or additional wording to explain 
+>> this e-mail editor folded it!) I don't know what the appropriate
+>> answer is here, but this can't be in the RM as written; we need an
+>> alternative that fits in one line or additional wording to explain
 >> the extra line breaks.
 >>
-> 
+>
 > Like you, I'm not sure what to do here. Some thought is required.
-> 
+>
 
 How about:
 
@@ -2550,7 +2497,7 @@
 >> Wide_Wide_String'Write and or Wide_Wide_String'Output)”
 > – maybe “and/or”  or just “or”?
 
-Or maybe just eliminate the reference to Wide_Wide_String'Output, so it 
+Or maybe just eliminate the reference to Wide_Wide_String'Output, so it
 becomes just "using Wide_Wide_String'Write". I'm not sure what I was thinking
 of when I mentioned 'Output.
 
@@ -2617,89 +2564,89 @@
 > >> (C2)
 ...
 > Ok, use J.15.12 (pragma Relative_Deadline) or D.2.2 (pragma
-> Priority_Specific_Dispatching) as templates (in particular, with 
+> Priority_Specific_Dispatching) as templates (in particular, with
 > respect to fonts) and replace the above with
 
 I take it from this that you are expecting me (your overworked editor :-) to
 make these updates? I'll do them, but I surely don't want to duplicate effort.
 
 >      Syntax
-> 
+>
 >      The form of a Default_Max_Image_Elements pragma is
 >      as follows:
-> 
+>
 >        pragma Default_Max_Image_Elements (stream_offset_expression);
-> 
+>
 >     Name Resolution Rules
 >        The expected type for a stream_offset_expression is
 >        Ada.Streams.Stream_Offset
-> 
+>
 > (do we, by convention, omit the "Ada." in "Ada.Streams"?)
 
-Usually, a convention I hate and often forget. My recollection was that it was 
-in response to a complaint that Ada 9x was too wordy; it eliminated some words 
-without actually requiring any effort to do so. And it has no descernable 
+Usually, a convention I hate and often forget. My recollection was that it was
+in response to a complaint that Ada 9x was too wordy; it eliminated some words
+without actually requiring any effort to do so. And it has no descernable
 effect on the size of the Standard (any gains made disappear in clause breaks
 and the like). Grump.
- 
+
 ...
-> >> (C3) You probably ought to add a paragraph to the discussion 
-> >> describing the model and use of Bounded_Stream. I know why it's 
-> >> there ('cause you told me), but it doesn't seem to be mentioned 
+> >> (C3) You probably ought to add a paragraph to the discussion
+> >> describing the model and use of Bounded_Stream. I know why it's
+> >> there ('cause you told me), but it doesn't seem to be mentioned
 > >> anywhere in the AI.
 > >>
-> > 
+> >
 > > It's there for the same reason that we provide the bounded containers.
-> > 
-> 
-> Note that the only text along these lines that we have for bounded 
+> >
+>
+> Note that the only text along these lines that we have for bounded
 > containers is A.18's AARM text
 >     "Similarly, a separate bounded version is provided in order to give
 >     more predictable memory usage."
-> 
+>
 > So immediately after the proposed implementation advice
-> 
+>
 >     Bounded_Stream objects should be implemented without implicit
 >     pointers or dynamic allocation.
-> 
+>
 > We add
-> 
+>
 >     [AARM: The Counted_Streams.Bounded package is provided in order to
 >     make available an alternative to the Counted_Streams.Unbounded
 >     package which gives more predictable memory usage.]
 
-Fine, but you totally missed my point. You have a pragma and a package and 
+Fine, but you totally missed my point. You have a pragma and a package and
 some other disconnected things, but nowhere you do you layout the model. At a
 minimum, we need something like:
 
-   The default model of Put_Image uses unbounded streams, which necessarily 
-   involves some dynamic memory allocation. Since Ada is widely used by 
-   systems that require predictable memory usage, we provide an alternative 
-   model for Put_Image that provides that. Such a user should apply 
-   Silly_Pragma (** too lazy to look it up **) as a configuration pragma to 
+   The default model of Put_Image uses unbounded streams, which necessarily
+   involves some dynamic memory allocation. Since Ada is widely used by
+   systems that require predictable memory usage, we provide an alternative
+   model for Put_Image that provides that. Such a user should apply
+   Silly_Pragma (** too lazy to look it up **) as a configuration pragma to
    their entire system. This causes Bounded_Stream (*** and other facts?? **)
-   to be used for all calls to Put_Image rather than Unbounded_Streams, 
+   to be used for all calls to Put_Image rather than Unbounded_Streams,
    providing the needed memory predicability.
 
-I'm certain this requires more fleshing out (there's some value associated 
+I'm certain this requires more fleshing out (there's some value associated
 with Silly_Pragma, it needs to be mentioned here).
 
 ...
-> >> This is too long for a line in the RM. It will get folded somehow, 
-> >> and that would probably give an incorrect interpretation of the 
+> >> This is too long for a line in the RM. It will get folded somehow,
+> >> and that would probably give an incorrect interpretation of the
 > >> actual result.
 > >> (I see
-> >> this e-mail editor folded it!) I don't know what the appropriate 
-> >> answer is here, but this can't be in the RM as written; we need an 
-> >> alternative that fits in one line or additional wording to explain 
+> >> this e-mail editor folded it!) I don't know what the appropriate
+> >> answer is here, but this can't be in the RM as written; we need an
+> >> alternative that fits in one line or additional wording to explain
 > >> the extra line breaks.
 > >>
-> > 
+> >
 > > Like you, I'm not sure what to do here. Some thought is required.
-> > 
-> 
+> >
+>
 > How about:
-> 
+>
 >   This might generate an image such as
 >     ( 1 => ( 1 => ( 123 => True,  124 => False)
 >              2 => ( 123 => False,  124 => False)),
@@ -2708,7 +2655,7 @@
 >    except with each sequence of spaces and line breaks replaced
 >    with a single space (with two spaces in the case of the spaces
 >    between a comma and an integer literal).
-> 
+>
 > This isn't ideal; I'm (very) open to suggestions.
 
 It's OK enough by me, absent better ideas.
@@ -2717,18 +2664,18 @@
 ====
 ...
 > >  what are the – meant to be?
-> 
+>
 > I think Randy explained this stuff.
-> 
+>
 > Alternatively, a comic-strip character hit his thumb with a hammer.
 
 LoL.
 
 ...
 > > “Item (Item'First .. Last)'Length” (two places) – what is meant by this??
-> 
+>
 > In the first occurrence, we've got
-> 
+>
 >     overriding
 >     procedure Read (
 >      Stream : in out Unbounded_Stream;
@@ -2737,34 +2684,34 @@
 >      with Post =>
 >         Element_Count (Stream) =
 >         Element_Count (Stream)'Old - Item (Item'First .. Last)'Length;
-> 
-> The postcondition says that the final Element_Count is equal to the 
+>
+> The postcondition says that the final Element_Count is equal to the
 > old Element_Count minus the number of stream elements that were read.
 > The expression in question
 >      Item (Item'First .. Last)'Length
-> yields the number of stream elements that were read (at least that was 
+> yields the number of stream elements that were read (at least that was
 > my intent).
-> 
-> The second occurrence is the same thing except in the Bounded package 
+>
+> The second occurrence is the same thing except in the Bounded package
 > instead of the Unbounded package.
 
-Sure, but I wondered why you wrote 'Length rather than just writing the 
+Sure, but I wondered why you wrote 'Length rather than just writing the
 answer. That is, for any array with integer indices,
 
     Arr(A..B)'Length == (if A <= B then B - A + 1 else 0)
 
-The attribute form requires evaluating the prefix and the condition, but in 
-this case we know that Last + 1 >= Item'First, so the evaluating neither is 
-necessary. (And I doubt that a compiler can figure that out -- it would 
-require detailed rummaging in the body of the routine -- SPARK may be able 
+The attribute form requires evaluating the prefix and the condition, but in
+this case we know that Last + 1 >= Item'First, so the evaluating neither is
+necessary. (And I doubt that a compiler can figure that out -- it would
+require detailed rummaging in the body of the routine -- SPARK may be able
 to, of course.)
 
 So I probably would have written:
 
     Last - Item'First + 1 -- Number of characters read (or returned?)
 
-for this value. I suppose your original expression is closer to 
-self-documenting, but even that isn't the case judging from Jeff's 
+for this value. I suppose your original expression is closer to
+self-documenting, but even that isn't the case judging from Jeff's
 question.
 
 ***************************************************************
@@ -2775,9 +2722,9 @@
 >>>> (C2)
 > ...
 >> Ok, use J.15.12 (pragma Relative_Deadline) or D.2.2 (pragma
->> Priority_Specific_Dispatching) as templates (in particular, with 
+>> Priority_Specific_Dispatching) as templates (in particular, with
 >> respect to fonts) and replace the above with
-> 
+>
 > I take it from this that you are expecting me (your overworked editor :-)
 > to make these updates? I'll do them, but I surely don't want to duplicate
 > effort.
@@ -2786,33 +2733,33 @@
 
 >
 > ...
->>>> (C3) You probably ought to add a paragraph to the discussion 
->>>> describing the model and use of Bounded_Stream. I know why it's 
->>>> there ('cause you told me), but it doesn't seem to be mentioned 
+>>>> (C3) You probably ought to add a paragraph to the discussion
+>>>> describing the model and use of Bounded_Stream. I know why it's
+>>>> there ('cause you told me), but it doesn't seem to be mentioned
 >>>> anywhere in the AI.
 
-> 
-> Fine, but you totally missed my point. You have a pragma and a package and 
-> some other disconnected things, but nowhere you do you layout the model. 
+>
+> Fine, but you totally missed my point. You have a pragma and a package and
+> some other disconnected things, but nowhere you do you layout the model.
 > At a minimum, we need something like: ...
-> 
+>
 
-I'll agree that we need some such text after you show me the corresponding 
+I'll agree that we need some such text after you show me the corresponding
 text for the bounded containers (and this is not just rhetorical - there is
-a real chance that the wording is there and I overlooked it). If we didn't 
-need such wording in the case of the containers, then IMO we don't need it 
+a real chance that the wording is there and I overlooked it). If we didn't
+need such wording in the case of the containers, then IMO we don't need it
 here.
 
-> 
+>
 > So I probably would have written:
-> 
+>
 >      Last - Item'First + 1 -- Number of characters read (or returned?)
-> 
-> for this value. I suppose your original expression is closer to 
-> self-documenting, but even that isn't the case judging from Jeff's 
+>
+> for this value. I suppose your original expression is closer to
+> self-documenting, but even that isn't the case judging from Jeff's
 > question.
 
-I say stick with what I proposed for now in the AI and we can flip a coin in 
+I say stick with what I proposed for now in the AI and we can flip a coin in
 Lisbon. Either way is fine with me, but I have a weak preference for the way I
 originally wrote it.
 
@@ -2823,10 +2770,10 @@
 From: Randy Brukardt
 Sent: Thursday, June 14, 2018  6:17 PM
 
-> I'll agree that we need some such text after you show me the 
-> corresponding text for the bounded containers (and this is 
-> not just rhetorical - there is a real chance that the wording 
-> is there and I overlooked it). If we didn't need such wording 
+> I'll agree that we need some such text after you show me the
+> corresponding text for the bounded containers (and this is
+> not just rhetorical - there is a real chance that the wording
+> is there and I overlooked it). If we didn't need such wording
 > in the case of the containers, then IMO we don't need it here.
 
 These aare completely different cases, IMHO. You don't need to use a
@@ -2849,23 +2796,23 @@
 From: Randy Brukardt
 Sent: Thursday, June 14, 2018  6:21 PM
 
-> I'll agree that we need some such text after you show me the 
-> corresponding text for the bounded containers (and this is not just 
-> rhetorical - there is a real chance that the wording is there and I 
-> overlooked it). If we didn't need such wording in the case of the 
+> I'll agree that we need some such text after you show me the
+> corresponding text for the bounded containers (and this is not just
+> rhetorical - there is a real chance that the wording is there and I
+> overlooked it). If we didn't need such wording in the case of the
 > containers, then IMO we don't need it here.
 
 Ignoring how silly a request this is, here's the start of the !discussion in
 AI05-0001-1:
 
-  The bounded forms are intended to bring determinism to the storage 
-  requirements of the various container forms. To this end, each bounded form 
-  includes Implementation Advice that no dynamic allocation or pointers are 
-  used to implement them. Thus, the bounded forms should be usable even in 
+  The bounded forms are intended to bring determinism to the storage
+  requirements of the various container forms. To this end, each bounded form
+  includes Implementation Advice that no dynamic allocation or pointers are
+  used to implement them. Thus, the bounded forms should be usable even in
   high-integrity contexts where dynamic allocation is forbidden.
 
-I am looking for something on this line explaining how the pragma and the 
-stream work together to provide this behavior for Image. Few people are going 
+I am looking for something on this line explaining how the pragma and the
+stream work together to provide this behavior for Image. Few people are going
 to be able to figure it out on their own.
 
 ***************************************************************
@@ -2873,22 +2820,22 @@
 From: Steve Baird
 Sent: Thursday, June 14, 2018  6:33 PM
 
-> Moreover, I'm talking about adding text into the !discussion to 
-> explain what the heck this pragma and Bounded_Stream type are doing 
-> there in the first place. It doesn't need to be in the RM (you often 
-> seem to be so fixed on the details that nothing else matters, but I 
-> want to be able to read one of these AIs in ten years and have some 
+> Moreover, I'm talking about adding text into the !discussion to
+> explain what the heck this pragma and Bounded_Stream type are doing
+> there in the first place. It doesn't need to be in the RM (you often
+> seem to be so fixed on the details that nothing else matters, but I
+> want to be able to read one of these AIs in ten years and have some
 > idea why we chose the design we did -- and it's clear that others do read
 > AIs for that sort of information).
-> *Nothing*  should appear in an AI without some explanation of why its 
+> *Nothing*  should appear in an AI without some explanation of why its
 > there and what it's for.
 
-Ok, I completely agree about !discussion . I thought you were talking about 
+Ok, I completely agree about !discussion . I thought you were talking about
 AARM wording.
 
 I'll propose something shortly.
 
-Incidentally, since we are talking about things other than the !wording 
+Incidentally, since we are talking about things other than the !wording
 section, the !proposal section currently begins with
 
    T'Image is defined for all non-abstract types
@@ -2902,23 +2849,23 @@
 From: Steve Baird
 Sent: Thursday, June 14, 2018  7:13 PM
 
-> Ok, I completely agree about !discussion . I thought you were talking 
+> Ok, I completely agree about !discussion . I thought you were talking
 > about AARM wording.
-> 
+>
 > I'll propose something shortly.
 
 !discussion
 
-The expected (although not required) implementation of the package 
+The expected (although not required) implementation of the package
 Ada.Streams.Counted_Streams.Unbounded involves dynamic storage allocation of some
 kind, perhaps accompanied with uses of controlled types.
 
-For some applications with high integrity/reliability requirements, those 
-requirements (more specifically, requirements about predictable memory 
+For some applications with high integrity/reliability requirements, those
+requirements (more specifically, requirements about predictable memory
 utilization) might preclude use of this package.
 
-Nonetheless, we would like such applications to be able to use T'Image for a 
-non-scalar type T without having to override the default implementation of 
+Nonetheless, we would like such applications to be able to use T'Image for a
+non-scalar type T without having to override the default implementation of
 T'Put_Image.
 
 That is the motivation for introducing
@@ -2930,23 +2877,23 @@
        T'Max_Image_Elements and the default implementation
        of T'Put_Image .
 
-An application can specify T'Max_Image_Elements either explicitly or via a 
+An application can specify T'Max_Image_Elements either explicitly or via a
 Default_Max_Image_Elements configuration pragma. Having done that, the default
-implementation of T'Put_Image will reference Counted_Streams.Bounded instead 
+implementation of T'Put_Image will reference Counted_Streams.Bounded instead
 of Counted_Streams.Unbounded.
 
 This will achieve the desired goal.
 
-The cost is that the burden is on the user to choose a "good" value for 
+The cost is that the burden is on the user to choose a "good" value for
 T'Max_Image_Elements. If the value is too small, then a call to T'Put_Image
-may fail; if the value is too big, then the storage requirements of a call 
+may fail; if the value is too big, then the storage requirements of a call
 to T'Put_Image may be unnecessarily large.
 
 ====
 
 Put_Image is user-specifiable; Wide_Wide_Image is not.
 
-One could imagine instead allowing user-specified Wide_Wide_Image attributes 
+One could imagine instead allowing user-specified Wide_Wide_Image attributes
 and not bothering to define User_Put_Image at all.
 
 The drawback of this approach is that it would could introduce, at least for
@@ -2955,7 +2902,7 @@
 Given
     type T is record F1, F2, F3 : Integer; end record;
 
-the default implementation of T'Wide_Wide_Image could have been defined to be 
+the default implementation of T'Wide_Wide_Image could have been defined to be
 something like
 
       return "(F1 => " &
@@ -2968,7 +2915,7 @@
 
 but that's a lot of concatenation; the situation for arrays would be even worse.
 
-Furthermore, the two Ada.Streams.Counted_Streams packages (Bounded and 
+Furthermore, the two Ada.Streams.Counted_Streams packages (Bounded and
 Unbounded) seem like they will be useful in their own right.
 
 ***************************************************************
@@ -2977,32 +2924,32 @@
 Sent: Thursday, June 14, 2018  8:20 PM
 
 ...
-> Incidentally, since we are talking about things other than the 
+> Incidentally, since we are talking about things other than the
 > !wording section, the !proposal section currently begins with
-> 
+>
 >    T'Image is defined for all non-abstract types
-> 
+>
 > and this should probably be replaced with something like
-> 
+>
 >    T'Image is defined for (almost) all types.
 
-Humm. You describe Put_Image as working like streams. You have no rules for 
-abstract types, that seems weird so I went to look at the stream attribute 
-rules. It turns out that all of the abstract type rules have to do with 
+Humm. You describe Put_Image as working like streams. You have no rules for
+abstract types, that seems weird so I went to look at the stream attribute
+rules. It turns out that all of the abstract type rules have to do with
 function 'Input, so those don't apply here.
 
 But stream attributes do have 13.13.2(38.1/4):
 
-The subprogram name given in such an attribute_definition_clause or 
-aspect_specification shall statically denote a subprogram that is not an 
+The subprogram name given in such an attribute_definition_clause or
+aspect_specification shall statically denote a subprogram that is not an
 abstract subprogram. Furthermore, if a specific stream-oriented attribute is
-specified for an interface type, the subprogram name given in the 
+specified for an interface type, the subprogram name given in the
 attribute_definition_clause or aspect_specification shall statically denote a
 null procedure.
 
-You don't have such a rule, but it seems needed. (We don't want to be calling 
-abstract subprograms!) The second part seems to come from the fact that the 
-only primitive concrete operation of an interface is a null procedure. (I 
+You don't have such a rule, but it seems needed. (We don't want to be calling
+abstract subprograms!) The second part seems to come from the fact that the
+only primitive concrete operation of an interface is a null procedure. (I
 didn't look up the exact reason for it, it could have come from any one of
 6 AIs - streams were a mess years ago!)
 
@@ -3013,15 +2960,15 @@
 
 Good catches.
 
-I agree that we should be consistent with the treatment of the stream-oriented 
-attributes here. Would it be worth trying to factor this out in order to avoid 
+I agree that we should be consistent with the treatment of the stream-oriented
+attributes here. Would it be worth trying to factor this out in order to avoid
 duplication? Perhaps a general 13.1.1 rule that, unless otherwise specified
 for a particular aspect, the subprogram named in an aspect specification for a
-subprogram-valued aspect shall not be abstract? Then we'd have to go find and 
+subprogram-valued aspect shall not be abstract? Then we'd have to go find and
 remove all the existing wording that would become redundant as a result of
 this change.
 
-It wouldn't bother me to outlaw specifying Put_Image for an interface type, 
+It wouldn't bother me to outlaw specifying Put_Image for an interface type,
 except that I agree that we want to be consistent with the streaming stuff. So
 I agree with your suggestion that we impose a "must be a null procedure" rule.
 
@@ -3030,10 +2977,10 @@
 From: Steve Baird
 Sent: Friday, June 15, 2018  7:41 PM
 
-> It wouldn't bother me to outlaw specifying Put_Image for an interface 
+> It wouldn't bother me to outlaw specifying Put_Image for an interface
 > type
 
-I take it back; that would cause contract problems for generics with formal 
+I take it back; that would cause contract problems for generics with formal
 types where the corresponding actual might or might not be an interface type.
 
 ***************************************************************
@@ -3041,38 +2988,38 @@
 From: Randy Brukardt
 Sent: Friday, June 15, 2018  7:54 PM
 
-> I agree that we should be consistent with the treatment of the 
-> stream-oriented attributes here. Would it be worth trying to factor 
-> this out in order to avoid duplication? Perhaps a general 13.1.1 rule 
-> that, unless otherwise specified for a particular aspect, the 
-> subprogram named in an aspect specification for a subprogram-valued 
-> aspect shall not be abstract? Then we'd have to go find and remove all 
-> the existing wording that would become redundant as a result of this 
+> I agree that we should be consistent with the treatment of the
+> stream-oriented attributes here. Would it be worth trying to factor
+> this out in order to avoid duplication? Perhaps a general 13.1.1 rule
+> that, unless otherwise specified for a particular aspect, the
+> subprogram named in an aspect specification for a subprogram-valued
+> aspect shall not be abstract? Then we'd have to go find and remove all
+> the existing wording that would become redundant as a result of this
 > change.
 
-It might make sense (not that I'm volunteering). The existing rule like that 
+It might make sense (not that I'm volunteering). The existing rule like that
 is 13.3(6), so I would think it would make the most sense to extend that.
-Alternatively, we might want to move that existing rule into 13.1 (since it 
+Alternatively, we might want to move that existing rule into 13.1 (since it
 should apply regardless of the syntax of specification), and then extend it.
-That would eliminate one more use of the blanket equivalence rule -- the 
+That would eliminate one more use of the blanket equivalence rule -- the
 fewer uses of that, the better.
 
 I.e.
 
-For the specification of an aspect that denotes a subprogram, the subprogram 
-shall not be abstract, the profile shall be mode conformant with the one 
-required for the aspect, and the convention shall be Ada. Additional 
-requirements are defined for particular aspects. 
-
-OTOH, the blanket rule doesn't work in reverse (aspect rules don't 
-automatically apply to attribute_definition_clauses), so it's unclear that 
-would work as written above. I'd have to look at how 13.1 works to get this 
+For the specification of an aspect that denotes a subprogram, the subprogram
+shall not be abstract, the profile shall be mode conformant with the one
+required for the aspect, and the convention shall be Ada. Additional
+requirements are defined for particular aspects.
+
+OTOH, the blanket rule doesn't work in reverse (aspect rules don't
+automatically apply to attribute_definition_clauses), so it's unclear that
+would work as written above. I'd have to look at how 13.1 works to get this
 wording right - I'll leave that to you (along with finding any wording that is
 unneeded after adding this).
 
-> It wouldn't bother me to outlaw specifying Put_Image for an interface 
-> type, except that I agree that we want to be consistent with the 
-> streaming stuff. So I agree with your suggestion that we impose a 
+> It wouldn't bother me to outlaw specifying Put_Image for an interface
+> type, except that I agree that we want to be consistent with the
+> streaming stuff. So I agree with your suggestion that we impose a
 > "must be a null procedure" rule .
 
 Yeah, it took a long time to get the rules for streams right, the less of that
@@ -3083,26 +3030,26 @@
 From: Steve Baird
 Sent: Monday, June 18, 2018  6:39 PM
 
->> I agree that we should be consistent with the treatment of the 
->> stream-oriented attributes here. Would it be worth trying to factor 
->> this out in order to avoid duplication? Perhaps a general 13.1.1 rule 
->> that, unless otherwise specified for a particular aspect, the 
->> subprogram named in an aspect specification for a subprogram-valued 
->> aspect shall not be abstract? Then we'd have to go find and remove 
->> all the existing wording that would become redundant as a result of 
+>> I agree that we should be consistent with the treatment of the
+>> stream-oriented attributes here. Would it be worth trying to factor
+>> this out in order to avoid duplication? Perhaps a general 13.1.1 rule
+>> that, unless otherwise specified for a particular aspect, the
+>> subprogram named in an aspect specification for a subprogram-valued
+>> aspect shall not be abstract? Then we'd have to go find and remove
+>> all the existing wording that would become redundant as a result of
 >> this change.
-> 
-> It might make sense (not that I'm volunteering). The existing rule 
+>
+> It might make sense (not that I'm volunteering). The existing rule
 > like that is 13.3(6), so I would think it would make the most sense to extend that.
-> Alternatively, we might want to move that existing rule into 13.1 
+> Alternatively, we might want to move that existing rule into 13.1
 > (since it should apply regardless of the syntax of specification), and then extend it.
-> That would eliminate one more use of the blanket equivalence rule -- 
+> That would eliminate one more use of the blanket equivalence rule --
 > the fewer uses of that, the better.
 
-Agreed. Even if we don't clean up the equivalence stuff at this point, let's 
+Agreed. Even if we don't clean up the equivalence stuff at this point, let's
 not make it worse.
 
-So suppose we add the following new paragraph in 13.1.1 immediately after 
+So suppose we add the following new paragraph in 13.1.1 immediately after
 18.1/4 (i.e., just before getting into the "nonoverridable"
 rules):
 
@@ -3127,11 +3074,11 @@
     3) Constant_Indexing/Variable_Indexing
     4) Default_Iterator
 
-I could easily have missed some; for example, if you look for aspect 
+I could easily have missed some; for example, if you look for aspect
 definitions in K.1 which mention "subprogram", "function", "procedure" or
 "entry", you will not find Default_Iterator.
 
-So I went looking for existing wording that ought to be removed because the 
+So I went looking for existing wording that ought to be removed because the
 proposed change would render it redundant.
 
 1) Of course there is the streaming rule that started this whole
@@ -3162,7 +3109,7 @@
      ... is illegal" rule that we have in #3.
 
 So in summary, it looks like this new wording plugs some holes in
-3 out of 4 cases and the only wording that would need to be removed is 
+3 out of 4 cases and the only wording that would need to be removed is
 13.13.2(38.1/4).
 
 As always, any review is welcome.
@@ -3175,12 +3122,12 @@
 Sent: Tuesday, June 19, 2018  4:27 PM
 
 You are very confused about Stable_Properties. It takes a "list of functions"
-(or, if the new AI is approved, "an aggregate of function names"), not a 
+(or, if the new AI is approved, "an aggregate of function names"), not a
 "function", so regardless of whatever wording you are writing, it does not
 apply to Stable_Properties. Whether Stable_Properties needs an abstract rule
-of it's own is a separate question (it might not, since the name is required 
-to be a "property function", and I don't recall the rules that needs right 
-now. (I'm too tired to look, answering mail and going to bed...Jet Lag does 
+of it's own is a separate question (it might not, since the name is required
+to be a "property function", and I don't recall the rules that needs right
+now. (I'm too tired to look, answering mail and going to bed...Jet Lag does
 that to one.) I don't think it needs to be tied into the null procedure rule,
 since again it has to be a property *function*.
 
@@ -3189,19 +3136,19 @@
 From: Randy Brukardt
 Sent: Friday, June 29, 2018  7:43 PM
 
-I answered this one originally when I was jet lagged right after arriving in 
+I answered this one originally when I was jet lagged right after arriving in
 Lisbon. Let me finish the thought...
 
 ...
-> So suppose we add the following new paragraph in 13.1.1 immediately 
-> after 18.1/4 (i.e., just before getting into the "nonoverridable" 
+> So suppose we add the following new paragraph in 13.1.1 immediately
+> after 18.1/4 (i.e., just before getting into the "nonoverridable"
 > rules):
-> 
+>
 >    Unless otherwise specified for a particular aspect, the subprogram
 >    named in an aspect_specification, an attribute_definition_clause
 >    or a pragma which specifies a subprogram-valued aspect shall not be
 >    abstract.
-> 
+>
 >    Unless otherwise specified for a particular aspect,
 >    if a subprogram-valued aspect is specified for an interface type,
 >    the subprogram name given in the aspect_specification,
@@ -3210,37 +3157,37 @@
 >    stream-oriented attributes [(i.e., Read'Class, Write'Class,
 >    Input'Class, and Ouput'Class)].
 
-Generally, rules that apply to all kinds of aspects belong in 13.1; 13.1.1 is 
-about rules that only apply to aspect_specifications. Otherwise, this looks 
+Generally, rules that apply to all kinds of aspects belong in 13.1; 13.1.1 is
+about rules that only apply to aspect_specifications. Otherwise, this looks
 fine to me.
 
-> In addition to the new Put_Image aspect that is introduced in this AI, 
-> I think this rule would also apply to the following already-defined 
+> In addition to the new Put_Image aspect that is introduced in this AI,
+> I think this rule would also apply to the following already-defined
 > aspects:
-> 
+>
 >     1) Read/Write/Input/Ouput['Class]
 >     2) Stable_Properties['Class]
 >     3) Constant_Indexing/Variable_Indexing
 >     4) Default_Iterator
-> 
-> I could easily have missed some; for example, if you look for aspect 
-> definitions in K.1 which mention "subprogram", "function", "procedure" 
+>
+> I could easily have missed some; for example, if you look for aspect
+> definitions in K.1 which mention "subprogram", "function", "procedure"
 > or "entry", you will not find Default_Iterator.
-> 
-> So I went looking for existing wording that ought to be removed 
+>
+> So I went looking for existing wording that ought to be removed
 > because the proposed change would render it redundant.
-> 
+>
 > 1) Of course there is the streaming rule that started this whole
 >     business, 13.13.2(38.1/4). That paragraph would need to be removed.
-> 
+>
 > 2) For Stable_Properties, I didn't find any such rule (which seems like
 >     an oversight in the Stable_Properties definition). We probably also
 >     don't want to allow specifying Stable_Properties (as opposed to
 >     Stable_Properties'Class) for an abstract type, but that's a separate
 >     question.
 
-I partially previously answered this one. But we do need a rule that disallows 
-abstract functions for Stable_Properties (it seems OK for 
+I partially previously answered this one. But we do need a rule that disallows
+abstract functions for Stable_Properties (it seems OK for
 Stable_Properties'Class), and also abstract types for Stable_Properties.
 
 So:
@@ -3249,21 +3196,21 @@
 
 "The aspect Stable_Properties shall not be specified for an abstract type."
 
-AARM Ramification: The above rule does not apply to Stable_Properties'Class 
+AARM Ramification: The above rule does not apply to Stable_Properties'Class
 aspects.
 
 Add after 7.3.4(13/5):
 
-"Furthermore, a stable property function used in a Stable_Properties aspect 
+"Furthermore, a stable property function used in a Stable_Properties aspect
 shall not be abstract."
 
-AARM Ramification: The above rule does not apply in Stable_Properties'Class 
+AARM Ramification: The above rule does not apply in Stable_Properties'Class
 aspects.
 
 > 3) For Constant_Indexing/Variable_Indexing, I also don't think any
 >     wording change is needed (and, with #2, I think this new wording
 >     plugs some holes).
-> 
+>
 >     This case is (sort of) handled by the existing 4.1.6 rule
 >       A generalized_indexing is illegal if the equivalent prefixed view
 >       (see below) is illegal.
@@ -3273,7 +3220,7 @@
 >     subprogram for a nonoverridable aspect doesn't seem like something
 >     we want to allow).
 
-Right. The new rule seems like an improvement; if no possible call would be 
+Right. The new rule seems like an improvement; if no possible call would be
 legal, why allow the aspect specification?
 
 > 4) Same situation as #3, including the fact that this is another
@@ -3281,22 +3228,116 @@
 >     don't have anything analogous to the "is illegal if the equivalent
 >      ... is illegal" rule that we have in #3.
 
-We have 5.5.2(6.2/4), which makes the iterator illegal if the Default Iterator 
-function call is illegal; so there is no hole. (There *was* a reason for this 
+We have 5.5.2(6.2/4), which makes the iterator illegal if the Default Iterator
+function call is illegal; so there is no hole. (There *was* a reason for this
 generically defined rule; it was originally added to catch constant containers
 when the parameter is "in out").
 
-Again, the new rule seems like an improvement, but it's not strictly 
+Again, the new rule seems like an improvement, but it's not strictly
 necessary.
 
 > So in summary, it looks like this new wording plugs some holes in
-> 3 out of 4 cases and the only wording that would need to be removed is 
+> 3 out of 4 cases and the only wording that would need to be removed is
 > 13.13.2(38.1/4).
-> 
+>
 > As always, any review is welcome.
-> 
+>
 > And yes, I know this is way past the deadline.
 
 I was too tired to complain. ;-)
 
 **************************************************************
+
+From: Steve Baird
+Sent: Friday, October 5, 2018  5:02 PM
+
+The attached is a new version of this AI, incorporating the feedback from the
+Lisbon meeting.
+
+It is actually 2 AIs (one of them hasn't been assigned a number yet) because
+part of that Lisbon feedback was the suggestion that the AI should be split into
+two parts. The other AI just defines some new predefined units,
+Ada.Streams.FIFO_Streams and a couple of child units thereof. [This is
+version /05 of this AI; the split AI was assigned AI12-0293-1 - Editor.]
+
+As usual, thanks to Randy for some helpful preliminary review. Also as usual,
+don't blame him for any flaws.
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 14, 2018  6:56 PM
+
+> The attached is a new version of this AI, incorporating the
+> feedback from the Lisbon meeting.
+>
+> It is actually 2 AIs (one of them hasn't been assigned a number
+> yet) because part of that Lisbon feedback was the suggestion
+> that the AI should be split into two parts. The other AI just
+> defines some new predefined units, Ada.Streams.FIFO_Streams
+> and a couple of child units thereof.
+
+That will be AI12-0293-1.
+
+> As usual, thanks to Randy for some helpful preliminary
+> review. Also as usual, don't blame him for any flaws.
+
+Of course. :-) Some nitpicks:
+
+>    For scalars - same image that Wide_Wide_Image has always generated
+>     since it was introduced in Ada95.
+
+Wide_Wide_Image was introduced in Ada 2005. Ada 95 had Wide_Image (only). Some
+of the details of Image have been changed in recent Ada versions as well
+(especially for Character et. al.). So I'm not sure of the best possible
+replacement here (just saying "Ada 2005" doesn't seem to have the intended
+impact).
+
+>   For class-wide types, the image obtained from the specific
+>      type is prefixed with the name of the tag
+>      and a "'", yielding qualified expression syntax, as in
+>      "My_Pkg.My_Tagged_Type'(ABC => True, DEF => 123.45)".
+
+Is this the name of the type of the tag, or the external name of the tag? (The
+previous version was clear that it was the external name.) I'd add "external" in
+this text if that's the intent. But I'm not certain it ought to be: the external
+name might not have anything to do with a type name and it might not work well
+as an expanded name.
+
+>   S'Put_Image denotes a procedure with the following specification:
+>       S'Put_Image
+>           (Arg    : T;
+>            Stream : not null access Ada.Streams.Root_Stream_Type'Class);
+
+This is got to be the first Ada procedure I've seen without the keyword
+"procedure"! Compare to the declarations in 13.13.2. ("procedure" should go
+before the last S'Put_Image here).
+
+>   X'Wide_Wide_Image
+>      X'Wide_Wide_Image denotes the result of calling function
+>      S'Wide_Wide_Image with Arg being X, where S is the nominal subtype of X.
+
+The lead-in text has disappeared here; we have no idea what X is here. I left
+the text from the previous version in the posted AI.
+
+>That is the motivation for introducing
+>    a) The package Ada.Streams.Counted_Streams.Bounded and its
+>       associated implementation advice.
+>    b) The aspect (and attribute) Max_Image_Elements
+>    c) The pragma Default_Max_Image_Elements.
+>    d) The interaction (for a given type T) between
+>       T'Max_Image_Elements and the default implementation
+>       of T'Put_Image .
+
+(a) is now in AI12-0293-1, and I believe that (b), (c), and (d) have been
+replaced by a restriction. There is a bunch of other discussion text that tries
+to explain (b), (c), and (d). That all needs to be replaced by text explaining
+how to use the restriction. I could have fixed (a), but the rest is too much.
+
+
+I did remove a double space before "of", and add a missing closing bracket ].
+And used the number 293 rather ??? in a couple of places. Otherwise, I left the
+original AI unchanged.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent