CVS difference for ai12s/ai12-0020-1.txt
--- ai12s/ai12-0020-1.txt 2018/10/19 05:59:53 1.15
+++ ai12s/ai12-0020-1.txt 2018/11/28 06:10:42 1.16
@@ -1,4 +1,4 @@
-!standard 4.10(0) 18-10-16 AI12-0020-1/06
+!standard 4.10(0) 18-10-22 AI12-0020-1/07
!standard 3.5(27.1/2)
!standard 3.5(55.1/5)
!standard 3.5(55.2/5)
@@ -7,6 +7,8 @@
!standard 13.13.1(9)
!standard 13.13.1(11)
!class Amendment 12-02-14
+!status Amendment 1-2012 18-11-27
+!status ARG Approved 8-0-0 18-10-22
!status work item 12-02-14
!status received 11-10-13
!priority Medium
@@ -46,7 +48,7 @@
a Wide_Wide_String representing the value in display form.
That Wide_Wide_String value is determined (approximately) as follows:
- For scalars - the same image that Wide_Wide_Image already generated before
+ For scalars - the same image that Wide_Wide_Image already generated before
this AI.
For access types -
Integer value displayed as a hex digits preceded by an '@',
@@ -104,7 +106,7 @@
Add a new subclause
- 4.10 Images
+ 4.10 Image Attributes
Static Semantics
@@ -166,20 +168,6 @@
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
@@ -193,14 +181,14 @@
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
- attributes were defined only for scalar types. The definition of these
- 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.
+ AARM Discussion: In earlier versions of Ada, Image and related
+ attributes were defined only for scalar types. The definition
+ of these 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.
- [Editor's note: The AARM notes for scalar types come from the original
- definition of Image; they're unchanged here.]
+ [Editor's note: The rules and AARM notes for scalar types come
+ from the original definition of Image; they're unchanged here.]
For an integer type, the image written out is the corresponding
decimal literal, without underlines, leading zeros, exponent, or
@@ -208,7 +196,7 @@
a minus sign or a space.
AARM Implementation Note: If the machine supports negative zeros for
- signed integer types, it is not specified whether " 0" or "–0" should
+ signed integer types, it is not specified whether " 0" or "-0" should
be returned for negative zero. We don't have enough experience with
such machines to know what is appropriate, and what other languages
do. In any case, the implementation should be consistent.
@@ -219,7 +207,7 @@
spaces are included. For a nongraphic character (a value of a character
type that has no enumeration literal associated with it), the value is
a corresponding language-defined name in upper case (for example,
- the image of the nongraphic character identified as nul is "NUL" —
+ the image of the nongraphic character identified as nul is "NUL" --
the quotes are not part of the image).
AARM Implementation Note: For an enumeration type T that has "holes"
@@ -265,43 +253,46 @@
it is not specified whether " 0.000" or "–0.000" is returned. See
corresponding comment above about integer types with signed zeros.
- 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 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.
-
- [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).]
-
- For an array type T, the default implementation of
- T'Put_Image generates an image based on (named, not positional)
- 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.
+ [Editor's note: End of pre-existing rules for scalar types.]
-
- [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)))
- although perhaps with different white space and/or line breaking.]
+ 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 left parenthesis
+ followed by "ACCESS", a space, and a sequence of graphic
+ characters, other than space or right parenthesis, representing the
+ location of the designated object, followed by a right parenthesis,
+ as in "(ACCESS FF0012AC)".
+
+ 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).
+
+ For an array type T, the default implementation of T'Put_Image
+ generates an image based on (named, not positional) array aggregate
+ syntax (with '[' and ']' as the delimiters) using calls to the
+ Put_Image procedures of the index type(s) and the element type to
+ generate images for values of those types.
+
+ 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]]]
+ 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.
- [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.]
+ 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 overall array is a null array and
+ has no actual elements.
The order in which components are written for
a composite type is the same canonical order in
@@ -313,27 +304,33 @@
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.
- Then Corresponding_Specific_Type'Put_Image is called.
-
- [AARM Implementation Note: This will typically require a dispatching call.]
-
- [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
- T itself) for which the Put_Image aspect has been Redunant[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.
-
- [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.]
+ Then S'Put_Image is called, where S is the specific type identified
+ by Arg'Tag.
+ AARM Implementation Note: This will typically require a dispatching
+ call.
+
+ 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 type extension, the default implementation of T'Put_Image
+ depends on whether there exists a noninterface ancestor of T (other
+ than T itself) for which the Put_Image aspect has been
+ Redundant[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_Image aspect has been specified.
+
+ 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.
@@ -347,8 +344,8 @@
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)".]
+ 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)". The image written out for a
@@ -364,11 +361,11 @@
because it does not need a write-lock, not because it returns a
meaningful result.]
- [TBH - 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) := ... ;
- pragma Assert (X'Image /= T1(X)'Image);]
+ pragma Assert (X'Image /= T1(X)'Image);
For an undiscriminated task type, the default implementation of T'Put_Image
generates an image of the form "(TASK <task_id_image>)"
@@ -380,8 +377,8 @@
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.]
+ 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:
@@ -437,6 +434,33 @@
[AARM note: This means that it is permitted to generate
"(F1 | F2 => TRUE)" instead of "(F1 => TRUE, F2 => TRUE)".]
+ - Additional spaces, carriage returns, and line feeds (Wide_Wide_Characters
+ with positions 32, 10, and 13, may be inserted
+ to improve readability of the generated image.
+
+Add after H.4(23):
+
+ Dynamic Semantics
+
+ The following *restriction_parameter*_identifier is language defined:
+
+ Max_Image_Length
+
+ Specifies the maximum length for a Wide_Wide_Image attribute result.
+ AARM note: Image and Wide_Image are defined in terms of
+ Wide_Wide_Image, so this restriction also applies to
+ evaluations of those attributes.
+ Violation of this restriction results in the raising of
+ Program_Error at the point of the invocation of an image
+ attribute.
+
+Add after H.4(23.8/2):
+
+ 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 within that partition without any dynamic allocation.
+
+
!discussion
@@ -455,9 +479,9 @@
That is the motivation for introducing the Max_Image_Length restriction. The
desired goal can be achieved by specifying a Max_Image_Length restriction.
-The cost is that the burden is on the user to choose a "good" value for the
+The cost is that the burden is on the user to choose a "good" value for the
restriction. If the value is too small, then a call to T'Put_Image may violate
-the restriction (at runtime); if the value is too big, then the storage
+the restriction (at runtime); if the value is too big, then the storage
requirements of a call to T'Put_Image may be unnecessarily large.
----
@@ -486,8 +510,9 @@
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
-Unbounded) seem like they will be useful in their own right.
+Furthermore, the two Ada.Streams.FIFO_Streams packages (Bounded and
+Unbounded) seem like they will be useful in their own right (now defined in
+AI12-0293-1).
----
@@ -503,7 +528,7 @@
With the current language definition, the assertion should succeed.
See the words "(after any implicit dereference)" in
-3.5(55.1/5); this wording was added as part of AI12-0124.
+3.5(55.1/5); this wording was added as part of AI12-0124-1.
With the proposed changes, the program remains legal but the assertion
will now fail because Ptr_Image will be initialized with the image of
@@ -3333,54 +3358,54 @@
Sent: Tuesday, October 16, 2018 6:28 PM
> 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
+>
+> 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).
-I suggest "the same image that Wide_Wide_Image already generated before
+I suggest "the same image that Wide_Wide_Image already generated before
this AI".
>> 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
+> (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.
-I think this lack of precision is fine in the !proposal section, particularly
-since this question is answered in the !wording section, where is says that
-Wide_Wide_Expanded_Name is called. I suggest that no action is needed for
+I think this lack of precision is fine in the !proposal section, particularly
+since this question is answered in the !wording section, where is says that
+Wide_Wide_Expanded_Name is called. I suggest that no action is needed for
this one.
>> S'Put_Image denotes a procedure with the following specification:
>> S'Put_Image
>> (Arg : T;
->> Stream : not null access
+>> 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.
+>
+> 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).
I agree. The word "procedure" is missing and should be added.
>> 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
+>> 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.
+>
+> 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.
Good catch! I don't know what happened to
@@ -3396,29 +3421,29 @@
>> 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
+>
+> (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.
-
+
Good point. This stuff was updated in the !wording but not in the !discussion.
Here is a possible replacement:
====
-That is the motivation for introducing the Max_Image_Length restriction. The
+That is the motivation for introducing the Max_Image_Length restriction. The
desired goal can be achieved by specifying a Max_Image_Length restriction.
-The cost is that the burden is on the user to choose a "good" value for the
+The cost is that the burden is on the user to choose a "good" value for the
restriction. If the value is too small, then a call to T'Put_Image may violate
-the restriction (at runtime); if the value is too big, then the storage
+the restriction (at runtime); if the value is too big, then the storage
requirements of a call to T'Put_Image may be unnecessarily large.
====
-> 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.
+> 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.
Thanks.
@@ -3443,8 +3468,8 @@
> Then Corresponding_Specific_Type'Put_Image is called. [At the
> implementation level this will typically require a dispatching call.]
-I don't think that the typical reader cares what the implementation might or
-might not do to implement the default version of this. So this "Redundant"
+I don't think that the typical reader cares what the implementation might or
+might not do to implement the default version of this. So this "Redundant"
statement (which is missing the "Redundant" lead-in) makes more sense as an
AARM implementation note.
@@ -3459,7 +3484,7 @@
---
-I also added "Redundant" in front of square brackets in the actual wording
+I also added "Redundant" in front of square brackets in the actual wording
(not AARM notes). Else someone could easily confuse that with a deletion.
****************************************************************
Questions? Ask the ACAA Technical Agent