Version 1.3 of ai12s/ai12-0315-1.txt
!standard 4.10(0) 19-02-26 AI12-0315-1/02
!reference AI12-0225-1
!class Amendment 19-02-15
!status Amendment 1-2012 19-02-14
!status ARG Approved 10-0-0 19-02-26
!status work item 19-02-15
!status received 19-02-14
!priority Low
!difficulty Easy
!subject Image Attributes subclause improvements
!summary
Add an introduction to the Image Attributes subclause.
Allow Image attributes for entities with type universal_integer, and the
prefix of an Image attribute can denote a value.
!problem
AI12-0225-1 corrected the definition of the "object" forms of Image attribute
to allow the prefix of an Image attribute to denote a value (like a named
number), and also to allow the prefix to denote an entity with type
universal_integer. Those changes got lost in the generalization of
Image attributes.
In addition, there should be some sort of introduction to the subclause;
leaping into what is primarily an implementation helper is a lousy way to
start the description.
!proposal
(See Summary.)
!wording
Add an introduction at the start of 4.10:
An image of a value is a string representing the value in display form.
The attributes Image, Wide_Image, and Wide_Wide_Image are available
to produce the image of a value as a String, Wide_String, or
Wide_Wide_String (respectively). User-defined images for a given type
can be implemented by overriding the default implementation of the
attribute Put_Image.
Modify 4.10(2/5):
For every subtype S of a [non-universal] type T{ other than universal_real
or universal_fixed}, the following type-related operational attribute
is defined:
Replace 4.10(3/5):
The default implementation of S'Put_Image writes (using Wide_Wide_String'Write)
an image of the value of Arg.
[Editor's note: This no longer defines "image", that is now in the introduction.]
Add a new AARM note after AARM 4.10(7.a/5):
AARM Discussion: We allow S'Put_Image when S is universal_integer or
root_integer, because the details of the desired string do not depend on
properties of an integer type. While S'Put_Image cannot be called directly for
these types (as they cannot be named), it can be called as part of evaluating
an Image attribute. Note that other rules of the language ensure that an
implementation can evaluate any universal_integer attribute using type
root_integer; therefore, Constraint_Error could be raised by the evaluation
of an Image attribute if the static value of the prefix is outside of the range
of root_integer.
Add a new AARM note after AARM 4.10(9.c/5):
AARM Reason: We do not allow S'Put_Image when S is universal_real, as
the details of the desired string depend on the properties of the
(specific) type of S. Specifically, universal_real does not have a defined
value for S'Digits.
Add a new AARM note after AARM 4.10(10.c/5):
AARM Reason: We do not allow S'Put_Image when S is universal_fixed, as
the details of the desired string depend on the properties of the
(specific) type of S. Specifically, universal_fixed does not have a defined
value for S'Aft.
Modify 4.10(31/5):
For a prefix X [that denotes an object ]of a [non-universal] type T {other than
universal_real or universal_fixed}, the following attributes are defined:
!discussion
See AI12-0225-1 for a detailed discussion of why we ought to allow values and
universal_integer values in particular.
!corrigendum 4.10(0)
Insert new clause:
This is a fake to cause a conflict; the real changes are found in the
conflict file.
!ASIS
[Not sure. It seems like some new capabilities might be needed,
but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are
supported.
!appendix
From: Randy Brukardt
Sent: Thursday, February 14, 2019 8:53 PM
During the discussion of AI12-0020-1, Steve showed an obscure incompatibility
caused by allowing Image for (almost) all types:
type Int_Ref is access Integer;
Ptr : Int_Ref := new Integer'(123);
Ptr_Image : String := Ptr'Image;
pragma Assert (Ptr_Image = Ptr.all'Image);
In Ada 2012, the assertion is True, in Ada 2020 it is not.
Given that these attributes were added by the Corrigendum to Ada 2012, this
isn't terribly critical.
However, we never discussed (so far as I recall) the more important
incompatibility. Ada 2012 TC1 allows universal types; we later "fixed" that to
exclude universal real and fixed types (that fix would be part of Ada 2020,
and thus will never happen). Moreover, the desciption of the attribute
reverted to require an object:
For a prefix X that denotes an object of a non-universal type T,
the following attributes are defined:
AI12-0225-1 details why this is a bad idea. Indeed, it makes it impossible to
use the object form of Image exclusively (as previously noted, in the worst
case it is only one character longer than the subtype form, so it would make
sense for an Ada style guide to consider the subtype form obsolete).
From the question of AI12-0225-1:
Limit : constant := 100;
Max : constant Natural := 100;
Put (Limit'Image); -- Error: (1)
Put (Max'Image); -- OK.
Put (Natural'(Limit)'Image); -- Error: (2)
Put (Natural'(100)'Image); -- Error: (3)
Put (Natural'(Max)'Image); -- OK.
Put (Natural(100)'Image); -- Error: (4)
Put (Natural(Max)'Image); -- Error: (5)
We eliminated this problem with AI12-0225-1 (well, except for
real literals/named numbers). I don't know why these changes were abandoned
(unless the author simply didn't use the draft RM to start - always a bad
idea).
I would guess that part of the reason is that Put_Image isn't defined for
universal_integer/root_integer, but there doesn't seem to be any important
reason that that isn't the case. No one could write an explicit call to that
attribute (since one can't use the names universal_integer or root_integer),
but there's no problem with the implicit call as part of X'Image.
So I would suggest that we change the lead-in for Put_Image (which is shared
with the subtype image, even though there is no reason to mention universal
subtypes there):
For every subtype S of any type T other than universal real or universal
fixed, the following type-related operational attributes are defined:
And the lead-in for the object form of Image should be something like:
For a prefix X of a type T other than universal real or universal fixed, the
following attributes are defined:
Otherwise, I'll have to document a rather substantial incompatibility which
was never intended for these attributes. (Note again that it is the
exclusion of universal real and universal fixed, as those don't make sense,
not the inclusion of universal integer, which is new for Ada 2020.)
Thoughts??
P.S. I'm wondering if there is a problem allowing universal access here. I
can't think of one, but I may not have a sufficiently fertile imagination.
P.P.S. It's certainly true that completely eliminating the difference between
objects and values for these sorts of purposes would be a better solution,
but the problem with that is that an object contains a value -- they're not
really the same thing. It seems to make more sense to reduce the number of
places where we require objects (why *can't* we rename values??) than to try
to make values and objects the same thing. Which is what was and still should
be done here. In any case, it's rather much too late to change the
value/object rules more this go-round.
****************************************************************
From: Steve Baird
Sent: Friday, February 15, 2019 12:51 PM
> For a prefix X of a type T other than universal real or universal
> fixed, the following attributes are defined:
Sounds right.
I don't see any problems with universal access. In particular, null'Image is
disallowed by syntax.
***************************************************************
From: Randy Brukardt
Sent: Thursday, February 14, 2019 8:14 PM
AI12-0020-1 does not include any introduction to 4.10 for Image attributes.
It just starts by defining Put_Image. There's enough text in this subclause
that some sort of introduction would seem like a good idea, especially as it
starts with the implementation mechanism rather than the user view.
Perhaps something like:
Attribute Image (and its siblings Wide_Image and Wide_Wide_Image) can be
used to retrieve a human-readable image of any Ada object. The default image
returned can be replaced by a user-defined version by replacing the
implementation of the Put_Image attribute.
Thoughts??
****************************************************************
From: Steve Baird
Sent: Friday, February 15, 2019 12:26 PM
I agree, intro text is a good idea here.
How about
The Image attribute of an object yields a String-valued
image of the value of the object. The Image attribute of a type T
yields a function which takes an argument of type T and returns
the image of that object. The related attributes
Wide_Image and Wide_Wide_Image are defined similarly except
that the resulting image is of type Wide_String or Wide_Wide_String.
User-defined images for a given type T can be implemented by
overriding the default implementation of the attribute
T'Put_Image.
?
****************************************************************
From: Randy Brukardt
Sent: Friday, February 15, 2019 3:02 PM
Your version here is a bit too descriptive, in that it mainly repeats the
formal definitions found below. In particular, I don't see any need to
enumerate precisely what arguments and results are possible in the
introductory text. And it never actually says what an image is for, which
seems like a key point.
The formal definition calls it "a representation of the value in display
form". I had suggested emphasizing that the value is intended for human
consumption. I think the first sentence needs to somehow do that.
One possibility is to move the formal definition of "image of a value" to the
introduction (and remove it from Put_Image). That would look something
like:
An *image* of a value is a string representing the value in display form.
The attributes Image, Wide_Image, and Wide_Wide_Image are provided to
generate the image of (almost) any value as a String, Wide_String, or
Wide_Wide_String. User-defined images for a given type T can be
implemented by overriding the default implementation of the attribute
T'Put_Image.
Then, the part starting "that is, " in Put_Image would be deleted.
Better??
****************************************************************
From: Tucker Taft
Sent: Friday, February 15, 2019 3:18 PM
The "(almost) any value" seems a bit weird. I think you can might say:
... The attributes Image, Wide_Image, and Wide_Wide_Image are available
to produce the image of a value as a String, Wide_String, or
Wide_Wide_String (respectively).
****************************************************************
From: Randy Brukardt
Sent: Friday, February 15, 2019 4:10 PM
>The "(almost) any value" seems a bit weird.
I said that because (even with the changes suggested in the other thread),
there does exist values that you can't take the image of. Specifically,
named numbers and the result of fixed * fixed multiplies:
A, B : Some_Fixed;
Num : constant := 2.718;
Num'Image -- Illegal, Universal real type.
"*"(A, B)'Image -- Illegal, Universal fixed type.
But I suppose it doesn't matter that the introduction is 100% accurate;
neither of these cases is particularly likely, and both can be handled with
qualification or type conversion. (Of course, qualifying either of these
gives a *different* value, thus they're not quite the same thing.)
>I think you can might say:
>
> ... The attributes Image, Wide_Image, and Wide_Wide_Image are
> available to produce the image of a value as a String, Wide_String, or
> Wide_Wide_String (respectively).
Sounds good to me.
****************************************************************
From: Tucker Taft
Sent: Friday, February 15, 2019 4:30 PM
> But I suppose it doesn't matter that the introduction is 100%
> accurate; neither of these cases is particularly likely, and both can
> be handled with qualification or type conversion. (Of course,
> qualifying either of these gives a *different* value, thus they're not
> quite the same thing.)
And it doesn't say "all values" it merely says "a value" so it is sufficiently
ambiguous as to be perfect fodder for an introduction. ;-)
****************************************************************
From: Steve Baird
Sent: Friday, February 15, 2019 4:55 PM
> Better??
Yes, although I agree with Tuck about "(almost) any". How about replacing
that with "a" or "a given".
****************************************************************
From: Tucker Taft
Sent: Saturday, February 16, 2019 8:28 AM
Not sure "a given" adds much in this context, but I am OK with it. Usually it
is more useful when you are later going to say "the given ...".
****************************************************************
Questions? Ask the ACAA Technical Agent