On Friday, 25 August 2023 at 14:02:57 UTC+1, Dmitry A. Kazakov wrote:
> On 2023-08-25 11:04, Stephen Davies wrote:
> The proposal was to add parameters defaulted to the existing behavior.
> Year'Image (Plus=>None,Width=>4,Alignment=>Right,Padding=>'0')
>
> > So the programmer could use 'User_Image to generate a display string
> > that will be formatted to the users preferences without knowing
> > (or being able to make assumptions about) those preferences,
> > e.g. Put_Line ("The result is " & Result'User_Image)
> This will be rejected on the same grounds as the original proposal.
> Read Randy's response.
I did read Randy's response, he explained the difficulty in adding
parameters to 'Image, so I suggested an alternative parameter-less
attribute. You could allow the output of this attribute to be
configurable by either some package data (c.f. Text_IO.Default_Width)
and/or by the OS. To be honest, all I really want is an attribute that
any Ada program can use to get a string suitable for output to its
users, i.e no leading space and exponentiation only used when needed.

On 2023-08-28 11:18, Stephen Davies wrote:

> I did read Randy's response, he explained the difficulty in adding
> parameters to 'Image,

He rather explained that this will never happen... (:-))

There is no good reason why attributes should not have the same
parameter syntax as subprograms and entry calls. Neither there is one
why 'Image must be a non-overridable attribute or why different classes
of types must have same parameter lists in their 'Image.

> so I suggested an alternative parameter-less
> attribute. You could allow the output of this attribute to be
> configurable by either some package data (c.f. Text_IO.Default_Width)
> and/or by the OS. To be honest, all I really want is an attribute that
> any Ada program can use to get a string suitable for output to its
> users, i.e no leading space and exponentiation only used when needed.

This will not happen either. But here I would agree, it is clearly a
case of language littering.

However see the GNAT-specific 'Img attribute. For debugging purposes it
does not add space where 'Image also for debugging purposes adds! (:-))

As Chairman Mao used to say: "In a word, while the prospects are bright,
the road has twists and turns." (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
> On 2023-08-28 11:18, Stephen Davies wrote:
> This will not happen either. But here I would agree, it is clearly a
> case of language littering.

Littering, schmittering, how about adding Bin_Image, Oct_Image & Hex_Image
for Ints and Dec_Image for Ints & Reals ;-)

> However see the GNAT-specific 'Img attribute. For debugging purposes it
> does not add space where 'Image also for debugging purposes adds! (:-))

Unless this changed recently, 'Img also adds a leading space.

On 2023-08-28 17:42, Stephen Davies wrote:
> On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
>> On 2023-08-28 11:18, Stephen Davies wrote:
>> This will not happen either. But here I would agree, it is clearly a
>> case of language littering.
>
> Littering, schmittering, how about adding Bin_Image, Oct_Image & Hex_Image
> for Ints and Dec_Image for Ints & Reals ;-)

Bin_Width_1_Image, Dec_Width_4_Image and so on... Cool, make Ada C
again! (:-))

>> However see the GNAT-specific 'Img attribute. For debugging purposes it
>> does not add space where 'Image also for debugging purposes adds! (:-))
>
> Unless this changed recently, 'Img also adds a leading space.

I see, the same mess then...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 28.08.23 18:09, Dmitry A. Kazakov wrote:
> On 2023-08-28 17:42, Stephen Davies wrote:
>> On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
>>> On 2023-08-28 11:18, Stephen Davies wrote:
>>> This will not happen either. But here I would agree, it is clearly a
>>> case of language littering.
>>
>> Littering, schmittering, how about adding Bin_Image, Oct_Image & Hex_Image
>> for Ints and Dec_Image for Ints & Reals ;-)
>
> Bin_Width_1_Image, Dec_Width_4_Image and so on... Cool, make Ada C again! (:-))

Or maybe leave type attributes alone. Instead, let Ada.Streams
have I/O manipulating setters.

Then, in order to preserve the meaning of "corresponding S'Output"
(LRM 13.13.2) for every S'Input, add AI to the Ada run-time system.

On 2023-08-28 13:58, Dmitry A. Kazakov wrote:
> On 2023-08-28 11:18, Stephen Davies wrote:
>
>> I did read Randy's response, he explained the difficulty in adding
>> parameters to 'Image,
>
> He rather explained that this will never happen... (:-))
>
> There is no good reason why attributes should not have the same
> parameter syntax as subprograms and entry calls.

Yes in principle, but it is understandble that making this happen now
could impact both the language definition and various implementations in
non-trivial ways.

> Neither there is one
> why 'Image must be a non-overridable attribute

In Ada 2022, 'Image is defined to call the new attribute 'Put_Image,
which can be specified (ie. overridden) by the programmer for any type.

See http://www.ada-auth.org/standards/22rm/html/RM-4-10.html.

On 2023-08-28 19:58, Niklas Holsti wrote:
> On 2023-08-28 13:58, Dmitry A. Kazakov wrote:
>> On 2023-08-28 11:18, Stephen Davies wrote:
>>
>>> I did read Randy's response, he explained the difficulty in adding
>>> parameters to 'Image,
>>
>> He rather explained that this will never happen... (:-))
>>
>> There is no good reason why attributes should not have the same
>> parameter syntax as subprograms and entry calls.
>
> Yes in principle, but it is understandble that making this happen now
> could impact both the language definition and various implementations in
> non-trivial ways.

Comparing to the useless and damaging sediments the language collects
with each new release? (:-))

>> Neither there is one why 'Image must be a non-overridable attribute
>
> In Ada 2022, 'Image is defined to call the new attribute 'Put_Image,
> which can be specified (ie. overridden) by the programmer for any type.
>
> See http://www.ada-auth.org/standards/22rm/html/RM-4-10.html.

Ah, thanks. I vaguely remembered that there was a yet another ugly hack
that does not really solves anything significant, but could not find it.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 2023-08-28 19:33, G.B. wrote:
> On 28.08.23 18:09, Dmitry A. Kazakov wrote:
>> On 2023-08-28 17:42, Stephen Davies wrote:
>>> On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
>>>> On 2023-08-28 11:18, Stephen Davies wrote:
>>>> This will not happen either. But here I would agree, it is clearly a
>>>> case of language littering.
>>>
>>> Littering, schmittering, how about adding Bin_Image, Oct_Image &
>>> Hex_Image
>>> for Ints and Dec_Image for Ints & Reals ;-)
>>
>> Bin_Width_1_Image, Dec_Width_4_Image and so on... Cool, make Ada C
>> again! (:-))
>
> Or maybe leave type attributes alone. Instead, let Ada.Streams
> have I/O manipulating setters.
>
> Then,  in order to preserve the meaning of "corresponding S'Output"
> (LRM 13.13.2) for every S'Input, add AI to the Ada run-time system.

I like the idea of unification of serialization and formatting.

However it does not solve the problem of parameters. In GUI frameworks
facing this very problem the parameters for rendering are set into the
graphic context/surface.

E.g. in the case of string formatting you would need a global object to
set the parameters into. E.g. a set of procedures like
Ada.Text_IO.Set_Field_Width, Ada.Text_IO.Set_Integer_Base etc. That
would be incredibly boring and unsafe.

For stream serialization the parameters could be set on the stream
itself. Which might break a lot of code if you added them to
Root_Stream_Type.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:uchukd$1lnvp$1@dont-email.me...
> On 2023-08-28 11:18, Stephen Davies wrote:
>
....
>Neither there is one why 'Image must be a non-overridable attribute

There actually is a good reason for this. Attributes have global visibility.
So if you allowed overriding of attributes, then a with added or removed in
a remote part of a program could silently change the behavior of code that
has no knowledge of of the change. That would be bad for "programming in the
large". Note that Ada 95 was proven to have no such cases, and we've tried
very hard to avoid them.

One could imagine adding rather severe restrictions to overriding of
attributes to eliminate this problem (for instance, only allowing it for
primitive operations of the type), but that would eliminate all real value
of the feature (you can always use a primitive function and "use all" to get
the same effect without any new features).

For 'Image specifically, the design of the attribute doesn't work well for
composition (for Image for composite types), which is why Ada 2022 has a
separate attribute that can be overridden similar to a stream attribute.

Randy.

On 2023-09-07 03:04, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:uchukd$1lnvp$1@dont-email.me...
>> On 2023-08-28 11:18, Stephen Davies wrote:
>>
> ...
>> Neither there is one why 'Image must be a non-overridable attribute
>
> There actually is a good reason for this. Attributes have global visibility.
> So if you allowed overriding of attributes, then a with added or removed in
> a remote part of a program could silently change the behavior of code that
> has no knowledge of of the change. That would be bad for "programming in the
> large". Note that Ada 95 was proven to have no such cases, and we've tried
> very hard to avoid them.

Ah, but 'Image is for debugging only! (:-))

> One could imagine adding rather severe restrictions to overriding of
> attributes to eliminate this problem (for instance, only allowing it for
> primitive operations of the type), but that would eliminate all real value
> of the feature (you can always use a primitive function and "use all" to get
> the same effect without any new features).

It must be a new type:

type My_Integer is new Integer;
for My_Integer'Image use Foo;

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Thank you all for the interesting replies and apologies for not
replying sooner.

I've been using 'Gnat.formatted_Output' which I've found quite
useful. Unfortunately, it seems to be a little buggy with its formatting.

On Saturday, September 23, 2023 at 1:59:20 PM UTC+4, Rod Kay wrote:
>
> I've been using 'Gnat.formatted_Output' which I've found quite
> useful. Unfortunately, it seems to be a little buggy with its formatting.

You can take a look at VSS's Virtual_String_Templates and Formatters, see

https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-templates.ads
https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-formatters.ads

and an example of its use

https://github.com/AdaCore/gnatdoc/blob/3e94448ac57270caf4b4502f208f78e1d51da2b2/source/gnatdoc-messages.adb#L130

On 26/9/23 15:47, Vadim Godunko wrote:
> On Saturday, September 23, 2023 at 1:59:20 PM UTC+4, Rod Kay wrote:
>>
>> I've been using 'Gnat.formatted_Output' which I've found quite
>> useful. Unfortunately, it seems to be a little buggy with its formatting.
>
> You can take a look at VSS's Virtual_String_Templates and Formatters, see
>
> https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-templates.ads
> https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-formatters.ads
>
> and an example of its use
>
> https://github.com/AdaCore/gnatdoc/blob/3e94448ac57270caf4b4502f208f78e1d51da2b2/source/gnatdoc-messages.adb#L130

That looks really good! I'll try it out asap.

Thank you Vadim.