Version 1.4 of ai12s/ai12-0315-1.txt

Unformatted version of ai12s/ai12-0315-1.txt version 1.4
Other versions for file ai12s/ai12-0315-1.txt

!standard 4.10(0)          19-03-05 AI12-0315-1/03
!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. State that 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