Parameterised 'Image Attributes

Parameterised 'Image Attributes

[Rod Kay]

Hello.all,


    There has been some recent discussion on #ada irc regarding 
formatted output.

    Would it be possible/desirable to allow the 'Image attribute to have 
formatting parameters ? Something along the lines of ...


    put_Line (some_Integer'Image (Width => 5, Padding => '0'));


... and similar 'Image attribute parameters for other types.


    If the parameters have defaults, then there should not be any 
backwards compatibility issues (I think).


    Any thoughts ?



Regards.

Re: Parameterised 'Image Attributes

[Luke A. Guest]

On 18/08/2023 08:18, Rod Kay wrote:
> Hello.all,
> 
> 
>     There has been some recent discussion on #ada irc regarding 
> formatted output.
> 
>     Would it be possible/desirable to allow the 'Image attribute to have 
> formatting parameters ? Something along the lines of ...
> 
> 
>     put_Line (some_Integer'Image (Width => 5, Padding => '0'));
> 
> 
> ... and similar 'Image attribute parameters for other types.
> 
> 
>     If the parameters have defaults, then there should not be any 
> backwards compatibility issues (I think).

I wanted them for ages, but there was a conversation ages ago where 
someone on here said attributes were for "debugging only," yet that's 
not what the arm says.

Re: Parameterised 'Image Attributes

[Keith Thompson]

Rod Kay <rodakay5@gmail.com> writes:
>    There has been some recent discussion on #ada irc regarding
>    formatted output.
>
>    Would it be possible/desirable to allow the 'Image attribute to
>    have formatting parameters ? Something along the lines of ...
>
>
>    put_Line (some_Integer'Image (Width => 5, Padding => '0'));
>
>
> ... and similar 'Image attribute parameters for other types.
>
>
>    If the parameters have defaults, then there should not be any
>    backwards compatibility issues (I think).

TeleSoft's compiler (which I worked on) had 'Extended_Image and
'Extended_Value attributes that worked like that.  I found them quite
useful -- especially as an easy way to drop the leading space on
Integer'Image.

One small problem was that we had different parameters for integer
and enumeration types, which introduced an ambiguity for discrete
formal types.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Re: Parameterised 'Image Attributes

[J-P. Rosen]

Le 18/08/2023 à 10:25, Luke A. Guest a écrit :
> On 18/08/2023 08:18, Rod Kay wrote:
>> Hello.all,
>>     There has been some recent discussion on #ada irc regarding 
>> formatted output.
>>
>>     Would it be possible/desirable to allow the 'Image attribute to 
>> have formatting parameters ? Something along the lines of ...
>>
>>     put_Line (some_Integer'Image (Width => 5, Padding => '0'));
>>
>> ... and similar 'Image attribute parameters for other types.
>>
>>     If the parameters have defaults, then there should not be any 
>> backwards compatibility issues (I think).
> 
> I wanted them for ages, but there was a conversation ages ago where 
> someone on here said attributes were for "debugging only," yet that's 
> not what the arm says.
> 
The intent of the 'Image attribute is to have a quick representation, 
mainly for debugging purposes. If you want nice formatted output, use 
the Put procedure on String from Text_IO.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-19 11:14, J-P. Rosen wrote:

> The intent of the 'Image attribute is to have a quick representation, 
> mainly for debugging purposes.

It seems that for the vast majority of Ada users this intent was wrong...

> If you want nice formatted output, use 
> the Put procedure on String from Text_IO.

Put does not supersede 'Image. Put is I/O. 'Image is pure string 
formatting. Put is generic and requires instantiation of some package 
with some difficult to guess name. 'Image is built-in [statically] 
dispatching and generated automatically by the compiler.

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

Re: Parameterised 'Image Attributes

[Luke A. Guest]

On 19/08/2023 11:03, Dmitry A. Kazakov wrote:
> On 2023-08-19 11:14, J-P. Rosen wrote:
> 
>> The intent of the 'Image attribute is to have a quick representation, 
>> mainly for debugging purposes.
> 

Where does it say this in the rm? We certainly were not taught that 
'image was for debugging at uni.

> It seems that for the vast majority of Ada users this intent was wrong...

Yup.

Re: Parameterised 'Image Attributes

[J-P. Rosen]

Le 19/08/2023 à 12:03, Dmitry A. Kazakov a écrit :
> On 2023-08-19 11:14, J-P. Rosen wrote:
> 
>> The intent of the 'Image attribute is to have a quick representation, 
>> mainly for debugging purposes.
> 
> It seems that for the vast majority of Ada users this intent was wrong...
The vast majority of Ada users ignore a number of useful features 
provided by the language, and keep asking for improvements that are 
already there...
>> If you want nice formatted output, use the Put procedure on String 
>> from Text_IO.
> 
> Put does not supersede 'Image. Put is I/O. 'Image is pure string 
> formatting. Put is generic and requires instantiation of some package 
> with some difficult to guess name. 'Image is built-in [statically] 
> dispatching and generated automatically by the compiler.
> 
Yes, put has nothing to do with 'Image. Yes, put requires instantiation. 
So what? Ada is more verbose, in favor of stricter typing. Ease of 
reading over ease of writing has always been a major design principle of 
Ada - although I confess it had a bad effect on its popularity, people 
want to write fast and ignore long term maintenance issues.

If you want formatting on an integer type (with or without IO), you 
instantiate Integer_IO. I don't find it hard to guess the name... Maybe 
you had something else in mind?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
https://www.adalog.fr https://www.adacontrol.fr

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-19 13:56, J-P. Rosen wrote:
> Le 19/08/2023 à 12:03, Dmitry A. Kazakov a écrit :
>> On 2023-08-19 11:14, J-P. Rosen wrote:
>>
>>> The intent of the 'Image attribute is to have a quick representation, 
>>> mainly for debugging purposes.
>>
>> It seems that for the vast majority of Ada users this intent was wrong...
> The vast majority of Ada users ignore a number of useful features 
> provided by the language, and keep asking for improvements that are 
> already there...

Or these features are not that useful? Language users and designers have 
often different perspectives...

>>> If you want nice formatted output, use the Put procedure on String 
>>> from Text_IO.
>>
>> Put does not supersede 'Image. Put is I/O. 'Image is pure string 
>> formatting. Put is generic and requires instantiation of some package 
>> with some difficult to guess name. 'Image is built-in [statically] 
>> dispatching and generated automatically by the compiler.
>>
> Yes, put has nothing to do with 'Image. Yes, put requires instantiation. 
> So what? Ada is more verbose, in favor of stricter typing.

I don't see how instantiation is stricter typing. In fact instantiation 
introduces overloading (static ad-hoc polymorphism) which was always 
frowned upon at as less type safe than overriding.

> Ease of 
> reading over ease of writing has always been a major design principle of 
> Ada - although I confess it had a bad effect on its popularity, people 
> want to write fast and ignore long term maintenance issues.

I don't buy this either. It is

    Put (X)  vs. X'Image

equally readable and writable. If you refer to the instantiation noise 
or with/use clauses you would require to but somewhere far above in the 
package. That is not ease of reading. That is just meaningless noise.

> If you want formatting on an integer type (with or without IO), you 
> instantiate Integer_IO. I don't find it hard to guess the name... Maybe 
> you had something else in mind?

Yes, all other types that might require formatting. I doubt anybody, but 
a language lawyer could name the package appropriate for formatting a 
fixed-point type without looking into the RM. Which is absolutely 
unneeded as 'Image would be perfectly OK if it had necessary parameters. 
All that generic text I/O packages are unnecessary as stream I/O case 
perfectly illustrates. Ada 95 did stream I/O if not right, but far 
better making 'Read, 'Write etc attributes overridable. The problem of 
generic mess solved. We do not have and do not need any generics for 
stream I/O. Good riddance.

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

Re: Parameterised 'Image Attributes

[Jeffrey R.Carter]

On 2023-08-19 11:14, J-P. Rosen wrote:
> On 18/08/2023 08:18, Rod Kay wrote:
>>
>>     Would it be possible/desirable to allow the 'Image attribute to have 
>> formatting parameters ? Something along the lines of ...
>
> The intent of the 'Image attribute is to have a quick representation, mainly for 
> debugging purposes. If you want nice formatted output, use the Put procedure on 
> String from Text_IO.

There is a common problem across many types and problem domains of having a 
function that returns a string of an appropriate length representing a value of 
the type with desired formatting. Common examples include numeric values, dates, 
and times. The resulting string is usually combined with other information into 
a message that may be stored in memory for a while, though it is rare for it not 
to be output eventually. As an example, the message may be put on a protected 
queue for later output by a logging task.

Ada 83 tended not to include anything that the developer could implement; there 
was no math library or image functions for dates or times. The 'Image attribute 
was provided, but is unsuited for most such uses.

The use of the Text_IO generic sub-pkg Put procedures that output to strings is 
not convenient because they are procedures, not functions.

Later versions of Ada included more support for such needs, but not for numeric 
values.

The obvious solution is to have a library containing appropriate functions, 
which can be built around the Put procedures while still being functions. Such 
functions would need to be generic, unlike attribute functions which are 
automatically available for all types.

The conflict between this common need and the minimal functionality provided by 
'Image results in such requests. It seems desirable for the language to provide 
such functions, and extending the 'Image functions seems like a reasonable way 
for it to do so, regardless of the original intentions for the attribute.

One library with such functions is the PragmAda Reusable Components 
(https://github.com/jrcarter/PragmARC). The package PragmARC.Images 
(https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-images.ads) provides 
such functions for integer and floating-point types. Function 
PragmARC.Images.Image is an instantiation for Standard.Integer.

PragmARC.Date_Handler 
(https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-date_handler.ads) 
provides image functions for dates and times; although the language now provides 
a function for a date-time image, Date_Handler continues to be useful as it 
provides for customized formats rather than the single format provided by 
Ada.Calendar.Formatting. Many users also find the semantics of the latter's 
time-zone parameter to be confusing.

(ISO/IEC 8652:2023 provides a date-time image function the returns the image for 
the local time zone, but as there are no compilers* for this version of the 
language, I don't consider that relevant.

(*A compiler for a version of the language implements the entire core language 
of that version of the ARM.)

-- 
Jeff Carter
"The men get one hot meal a day: a bowl of steam."
Take the Money and Run
145

Re: Parameterised 'Image Attributes

[moi]

On 19/08/2023 10:14, J-P. Rosen wrote:
> Le 18/08/2023 à 10:25, Luke A. Guest a écrit :
>> On 18/08/2023 08:18, Rod Kay wrote:
>>> Hello.all,
>>>     There has been some recent discussion on #ada irc regarding 
>>> formatted output.
>>>
>>>     Would it be possible/desirable to allow the 'Image attribute to 
>>> have formatting parameters ? Something along the lines of ...
>>>
>>>     put_Line (some_Integer'Image (Width => 5, Padding => '0'));
>>>
>>> ... and similar 'Image attribute parameters for other types.
>>>
>>>     If the parameters have defaults, then there should not be any 
>>> backwards compatibility issues (I think).
>>
>> I wanted them for ages, but there was a conversation ages ago where 
>> someone on here said attributes were for "debugging only," yet that's 
>> not what the arm says.
>>
> The intent of the 'Image attribute is to have a quick representation, 
> mainly for debugging purposes. If you want nice formatted output, use 
> the Put procedure on String from Text_IO.
> 

My code uses 'Image heavily, because it is usually the neatest and the
clearest way to format many strings that mingle words and numbers.

I sometimes have to pass the result of 'Image to a function that
implements the kind of functionality people are asking for,
and it would be even neater and clearer if I could get that with
parameters to 'Image itself.

None of that output has anything to do with debugging.

-- 
Bill F.

Re: Parameterised 'Image Attributes

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]

The profile of the Image attribute is:

    X'Image

where X is an object of any type (or value of most types). And the old, 
unnecessary form was:
   S'Image(X)
where S and X are of any type.

If one tries to add parameters to this, one gives up this nice form for a 
mis-mash of profiles for various classes of types. Moreover, the result no 
longer composes in the obvious way (necessary to have Image for records and 
arrays).

Additionally, one ends up with a magic mechanism that only the compiler can 
use. That *never* is a good idea. Especially as there now is a way to allow 
Image to support user-defined types. It would seem necessary to also support 
user-defined formatting parameters (else one has magic only applicable to a 
handful of language defined types).

Attributes do not allow named parameters outside a few special cases, and 
*never* allow reordering of parameters. Does that need to change, too?

Float input/output in particular is very large, especially when all of the 
formatting options are included. Do you really want to drag that into 
*every* Ada program, whether it uses it or not??

'Image is convinient for integer and enumeration output, and one can format 
them in the rare case where that is necessary. But it is useless for float 
output -- manual reformatting the output of 'Image would round the results 
incorrectly.

Ada has few built-in facilities because it's primary purpose is to support 
the development of proper ADTs. Ease of writing is not a goal at all, and in 
most cases, the extra text is valuable to compilers and tools (even if it is 
not so valuable to human readers). If it was up to me, I would eliminate 
most of the shortcuts from Ada and require everything to be written out. 
(IDEs could/should do most of that for you anyway, so the extra text is not 
adding much effort.)

Ergo, I hope this idea is dead-on-arrival. I certainly won't be involved in 
it, that's for sure.

                                      Randy.



"moi" <findlaybill@blueyonder.co.uk> wrote in message 
news:kkca55F9sn7U1@mid.individual.net...
> On 19/08/2023 10:14, J-P. Rosen wrote:
>> Le 18/08/2023 à 10:25, Luke A. Guest a écrit :
>>> On 18/08/2023 08:18, Rod Kay wrote:
>>>> Hello.all,
>>>> There has been some recent discussion on #ada irc regarding formatted 
>>>> output.
>>>>
>>>> Would it be possible/desirable to allow the 'Image attribute to have 
>>>> formatting parameters ? Something along the lines of ...
>>>>
>>>> put_Line (some_Integer'Image (Width => 5, Padding => '0'));
>>>>
>>>> ... and similar 'Image attribute parameters for other types.
>>>>
>>>> If the parameters have defaults, then there should not be any backwards 
>>>> compatibility issues (I think).
>>>
>>> I wanted them for ages, but there was a conversation ages ago where 
>>> someone on here said attributes were for "debugging only," yet that's 
>>> not what the arm says.
>>>
>> The intent of the 'Image attribute is to have a quick representation, 
>> mainly for debugging purposes. If you want nice formatted output, use the 
>> Put procedure on String from Text_IO.
>>
>
> My code uses 'Image heavily, because it is usually the neatest and the
> clearest way to format many strings that mingle words and numbers.
>
> I sometimes have to pass the result of 'Image to a function that
> implements the kind of functionality people are asking for,
> and it would be even neater and clearer if I could get that with
> parameters to 'Image itself.
>
> None of that output has anything to do with debugging.
>
> -- 
> Bill F.
> 

Re: Parameterised 'Image Attributes

[G.B.]

On 19.08.23 17:27, Jeffrey R.Carter wrote:
> On 2023-08-19 11:14, J-P. Rosen wrote:
>> On 18/08/2023 08:18, Rod Kay wrote:
>>>
>>>     Would it be possible/desirable to allow the 'Image attribute to have formatting parameters ? Something along the lines of ...
>>
>> The intent of the 'Image attribute is to have a quick representation, mainly for debugging purposes. If you want nice formatted output, use the Put procedure on String from Text_IO
> (...)
> The obvious solution is to have a library containing appropriate functions, which can be built around the Put procedures while still being functions. Such functions would need to be generic, unlike attribute functions which are automatically available for all types.
> 
> The conflict between this common need and the minimal functionality provided by 'Image results in such requests. It seems desirable for the language to provide such functions, and extending the 'Image functions seems like a reasonable way for it to do so, regardless of the original intentions for the attribute.

So, also

- See how other languages address formats (good bits,
   bad bits).
- Consider use cases.
- I/O is the program(mer)'s raison d'être. Can we easily Put
   something into a stream without the help of a suitable
   library?

Could there be a language defined type F whose purpose is to support
the description of formats? Objects of type F would "configure"
what 'Image does when computing a representation of a date, a number, ...

   My_Length'Image (Arg => diameter, Format => ___);

Some use cases:
- I18n of number formats (cf ARM F.3), CHF 1'234'000.–
- Handle ubiquitous ISO formats of date-time (as mentioned below;
   also cf. ARM 9.6.1)
- reporting,
- integrate own output with output of other system components
   (a site-wide monitoring system searches outputs, say)
- fill in templates when these do not support formatting
- 'Input an object of type F at run-time, so that program's
   use of 'Image can be changed according to customer's
   local expectations.
- support the formalized exchange of "numerical" data in
   heterogeneous systems, using text streams.

These use cases are about the O of I/O. By symmetry, it would be
nice to have implementations of Ada that support the I part of this
kind of I/O, I think, with work to be split between implementers
and programmers.

   My_Length'Value (Arg => diameter, Format => ___);

Or perhaps multimethods that take a stream and a format
when they need to write a value?


> One library with such functions is the PragmAda Reusable Components (https://github.com/jrcarter/PragmARC). The package PragmARC.Images (https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-images.ads) provides such functions for integer and floating-point types. Function PragmARC.Images.Image is an instantiation for Standard.Integer.
> 
> PragmARC.Date_Handler (https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-date_handler.ads) provides image functions for dates and times; although the language now provides a function for a date-time image, Date_Handler continues to be useful as it provides for customized formats rather than the single format provided by Ada.Calendar.Formatting. Many users also find the semantics of the latter's time-zone parameter to be confusing.
> 
> (ISO/IEC 8652:2023 provides a date-time image function the returns the image for the local time zone, but as there are no compilers* for this version of the language, I don't consider that relevant.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-20 09:53, G.B. wrote:

> Could there be a language defined type F whose purpose is to support
> the description of formats? Objects of type F would "configure"
> what 'Image does when computing a representation of a date, a number, ...

Not without multiple dispatch support and classes:

    Type x Format [ x Target ]

Otherwise you get an untyped mess as in C:

    printf ("%s", 123);

In the case of 'Image the dispatch is hard-wired. The compiler generates 
it according to one of built-in classes like 'integer type'. So yes it 
would be no problem to add parameters specific to each of the classes as 
well as common parameters like padding or alignment inside a field. But 
it will never ever happen.

You seem suggesting a class-wide parameter type instead:

    type Format_Type is tagged record
       Width     : Natural := 0;
       Alignment : Alignment_Type := Left;
       Padding   : Character := ' ';
    end record;
    type Integer_Format is new Format_Type with record
       Plus_Sign : Boolean := False;
       Base      : Base_Type := 10;
    end record;

    X'Image (Format => Format_Type'Class)

This still requires a change that will be outright rejected on highest 
philosophical grounds. (:-))

However with a Format_Type you do not need 'Image. You can simply use a 
binary operation, e.g.

    function "/" (Value : Integer; Format : Integer_Format)
       return String;

So would do

    Put_Line ("X=" & X / (Width=>10, Padding=>'0', Alignment=>Right));

instead of

    Put_Line ("X=" & X'Image (Width=>10, Padding=>'0', Alignment=>Right));

Of course it must be generic, which kills all fun.

Ergo

1. Compiler magic is necessary because the language type system is too 
weak to express things like formatting.

2. No proposal however useful and reasonable will survive ARG because of #1.

3. Use a library that does the stuff. E.g.

    http://www.dmitry-kazakov.de/ada/strings_edit.htm#Integer_Edit

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

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-20 09:25, Randy Brukardt wrote:

> Additionally, one ends up with a magic mechanism that only the compiler can
> use. That *never* is a good idea.

A better idea would be to improve the language to remove need in magic, 
but that is *never* a good idea either! (:-))

> Attributes do not allow named parameters outside a few special cases, and
> *never* allow reordering of parameters. Does that need to change, too?

Elementary! Attribute is just an alternative syntactic form of a 
subroutine call. There is no reason why attribute should be limited to 
look like FORTRAN IV! (:-))

> 'Image is convinient for integer and enumeration output, and one can format
> them in the rare case where that is necessary. But it is useless for float
> output -- manual reformatting the output of 'Image would round the results
> incorrectly.

Which is why Float 'Image must have parameters!

> Ada has few built-in facilities because it's primary purpose is to support
> the development of proper ADTs. Ease of writing is not a goal at all, and in
> most cases, the extra text is valuable to compilers and tools (even if it is
> not so valuable to human readers).

How is this related to attribute 'Image lacking necessary parameters? 
Why generic function having such parameters is OK, while 'Image with 
same parameters is not?

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

Re: Parameterised 'Image Attributes

[Randy Brukardt]

Your #3 is the point of course. If a reasonable library can be written, you 
should use that. After all, the Ada philosophy is that it is suspicious to 
use any built-in types. Why then should it be less suspicious to use other 
things that are built-in??

The best approach for Ada going forward is the add things that make it 
easier to build good libraries (as in user-defined literals). And minimize 
magic.

                       Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ubsmak$1a024$1@dont-email.me...
> On 2023-08-20 09:53, G.B. wrote:
>
>> Could there be a language defined type F whose purpose is to support
>> the description of formats? Objects of type F would "configure"
>> what 'Image does when computing a representation of a date, a number, ...
>
> Not without multiple dispatch support and classes:
>
>    Type x Format [ x Target ]
>
> Otherwise you get an untyped mess as in C:
>
>    printf ("%s", 123);
>
> In the case of 'Image the dispatch is hard-wired. The compiler generates 
> it according to one of built-in classes like 'integer type'. So yes it 
> would be no problem to add parameters specific to each of the classes as 
> well as common parameters like padding or alignment inside a field. But it 
> will never ever happen.
>
> You seem suggesting a class-wide parameter type instead:
>
>    type Format_Type is tagged record
>       Width     : Natural := 0;
>       Alignment : Alignment_Type := Left;
>       Padding   : Character := ' ';
>    end record;
>    type Integer_Format is new Format_Type with record
>       Plus_Sign : Boolean := False;
>       Base      : Base_Type := 10;
>    end record;
>
>    X'Image (Format => Format_Type'Class)
>
> This still requires a change that will be outright rejected on highest 
> philosophical grounds. (:-))
>
> However with a Format_Type you do not need 'Image. You can simply use a 
> binary operation, e.g.
>
>    function "/" (Value : Integer; Format : Integer_Format)
>       return String;
>
> So would do
>
>    Put_Line ("X=" & X / (Width=>10, Padding=>'0', Alignment=>Right));
>
> instead of
>
>    Put_Line ("X=" & X'Image (Width=>10, Padding=>'0', Alignment=>Right));
>
> Of course it must be generic, which kills all fun.
>
> Ergo
>
> 1. Compiler magic is necessary because the language type system is too 
> weak to express things like formatting.
>
> 2. No proposal however useful and reasonable will survive ARG because of 
> #1.
>
> 3. Use a library that does the stuff. E.g.
>
>    http://www.dmitry-kazakov.de/ada/strings_edit.htm#Integer_Edit
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
> 

Re: Parameterised 'Image Attributes

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ubsn75$1a024$2@dont-email.me...
> On 2023-08-20 09:25, Randy Brukardt wrote:
>
>> Additionally, one ends up with a magic mechanism that only the compiler 
>> can
>> use. That *never* is a good idea.
>
> A better idea would be to improve the language to remove need in magic, 
> but that is *never* a good idea either! (:-))

No, I generally agree with this. We probably disagree on what would 
consistute an improvement, however. ;-)

>> Attributes do not allow named parameters outside a few special cases, and
>> *never* allow reordering of parameters. Does that need to change, too?
>
> Elementary! Attribute is just an alternative syntactic form of a 
> subroutine call. There is no reason why attribute should be limited to 
> look like FORTRAN IV! (:-))

That turns out to be a bad idea. The reason people love attributes so is 
that they don't have to worry about visibility -- they're always visible. 
That is not and cannot be true for subprograms.

For example, the reason that we don't allow user-defined attributes is that 
they would compromise portability. Since they're always visible, they could 
hide/make illegal attributes that are used in units (like generic units) 
that don't know anything about the additions. Moreover, not all attributes 
can be described as subprograms given Ada's current rules (reduction 
attributes have a type parameter; some of the annex 13 attributes have "any 
type" parameters, etc.)

It certainly would be a very bad thing for Janus/Ada, which would have to 
have its resolution and subprogram definition mechanisms redesigned. (All 
subprograms are materialized in the Janus/Ada symboltable, in particular for 
visibility management reasons, and that would not be possible for 
attributes. Resolution only works on materialized subprogram definitions.)

>> 'Image is convinient for integer and enumeration output, and one can 
>> format
>> them in the rare case where that is necessary. But it is useless for 
>> float
>> output -- manual reformatting the output of 'Image would round the 
>> results
>> incorrectly.
>
> Which is why Float 'Image must have parameters!

Which is why one shouldn't use Float'Image! ;-)

>> Ada has few built-in facilities because it's primary purpose is to 
>> support
>> the development of proper ADTs. Ease of writing is not a goal at all, and 
>> in
>> most cases, the extra text is valuable to compilers and tools (even if it 
>> is
>> not so valuable to human readers).
>
> How is this related to attribute 'Image lacking necessary parameters? Why 
> generic function having such parameters is OK, while 'Image with same 
> parameters is not?

It's perfectly OK to overload functions however one wants, because you can 
keep anything that is problem from being considered by avoiding "use" (and 
"with").

'Image is not appropriate for an attribute in the first place; attributes 
are supposed to be simple compile-time defined properties of a type. String 
conversion is not that.

My preference for making Ada easier to use for this sort of thing is allow 
class-wide elementary types. Then one could have non-generic subnprograms 
that operation on all integer and float types. (Fixed and enumerations would 
still require generics, although I suspect most people would simply convert 
fixed to float for output rather than worrying about an instantiation.) That 
would make a library simple to use, and few people would think that 
something builr-in is needed.

                         Randy.

Re: Parameterised 'Image Attributes

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ubsmak$1a024$1@dont-email.me...
...
> Of course it must be generic, which kills all fun.

As noted in my other message, resurrecting the Ada 95 idea allowing 
class-wide types for elementary types would eliminate (or at least greatly 
reduce) this problem. I think that would be a more productive way to address 
this problem than hacking around with 'Image some more. (We've already 
proven that it is not a good way to define anything user-defined, thus the 
rather complex way to define such 'Image attributes.)

                                      Randy.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-22 01:37, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ubsmak$1a024$1@dont-email.me...
> ...
>> Of course it must be generic, which kills all fun.
> 
> As noted in my other message, resurrecting the Ada 95 idea allowing
> class-wide types for elementary types would eliminate (or at least greatly
> reduce) this problem.

Yes, but that would be a huge change.

> I think that would be a more productive way to address
> this problem than hacking around with 'Image some more. (We've already
> proven that it is not a good way to define anything user-defined, thus the
> rather complex way to define such 'Image attributes.)

One does not exclude another. If you allowed classes then there would be 
no reason not to have attributes official primitive operations. E.g. an 
"imaginable" interface would provide "'Image" and the standard Integer 
would inherit to "imaginable"...

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

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-22 01:34, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ubsn75$1a024$2@dont-email.me...
>> On 2023-08-20 09:25, Randy Brukardt wrote:
>>
>>> Additionally, one ends up with a magic mechanism that only the compiler
>>> can
>>> use. That *never* is a good idea.
>>
>> A better idea would be to improve the language to remove need in magic,
>> but that is *never* a good idea either! (:-))
> 
> No, I generally agree with this. We probably disagree on what would
> consistute an improvement, however. ;-)

To the same effect...

>>> Attributes do not allow named parameters outside a few special cases, and
>>> *never* allow reordering of parameters. Does that need to change, too?
>>
>> Elementary! Attribute is just an alternative syntactic form of a
>> subroutine call. There is no reason why attribute should be limited to
>> look like FORTRAN IV! (:-))
> 
> That turns out to be a bad idea. The reason people love attributes so is
> that they don't have to worry about visibility -- they're always visible.
> That is not and cannot be true for subprograms.
> 
> For example, the reason that we don't allow user-defined attributes is that
> they would compromise portability. Since they're always visible, they could
> hide/make illegal attributes that are used in units (like generic units)
> that don't know anything about the additions.

In other words attribute is a primitive subprogram, yes.

> Moreover, not all attributes
> can be described as subprograms given Ada's current rules (reduction
> attributes have a type parameter; some of the annex 13 attributes have "any
> type" parameters, etc.)

It is a primitive subprogram of some built-in class. The magic is not in 
the attribute, it is the class description. For magical classes 
overriding a primitive operation could look like

    for <member-type>'<primitive-operation-name> use <subroutine-name>;

> It certainly would be a very bad thing for Janus/Ada, which would have to
> have its resolution and subprogram definition mechanisms redesigned. (All
> subprograms are materialized in the Janus/Ada symboltable, in particular for
> visibility management reasons, and that would not be possible for
> attributes. Resolution only works on materialized subprogram definitions.)

Only if you wanted to remove all magic, which is never be possible. But 
you can do some.

>>> 'Image is convinient for integer and enumeration output, and one can
>>> format
>>> them in the rare case where that is necessary. But it is useless for
>>> float
>>> output -- manual reformatting the output of 'Image would round the
>>> results
>>> incorrectly.
>>
>> Which is why Float 'Image must have parameters!
> 
> Which is why one shouldn't use Float'Image! ;-)

Any application programmer will tell you that all types must have 
'Image! (:-))

>>> Ada has few built-in facilities because it's primary purpose is to
>>> support
>>> the development of proper ADTs. Ease of writing is not a goal at all, and
>>> in
>>> most cases, the extra text is valuable to compilers and tools (even if it
>>> is
>>> not so valuable to human readers).
>>
>> How is this related to attribute 'Image lacking necessary parameters? Why
>> generic function having such parameters is OK, while 'Image with same
>> parameters is not?
> 
> It's perfectly OK to overload functions however one wants, because you can
> keep anything that is problem from being considered by avoiding "use" (and
> "with").
> 
> 'Image is not appropriate for an attribute in the first place; attributes
> are supposed to be simple compile-time defined properties of a type. String
> conversion is not that.

But stream serialization is?

The problem is that whatever intention Ada designers had for attributes 
they also gave them property of being a primitive operation where no 
user-defined class allowed. This power steamrolls any "good" intentions.

Nobody loves the syntax T'Image (X) or X'Image! Give programmers X.Image 
and [<path-of-package-names-nobody-remembers>].Image (X) and they will 
forget about the attribute.

> My preference for making Ada easier to use for this sort of thing is allow
> class-wide elementary types. Then one could have non-generic subnprograms
> that operation on all integer and float types.

Yes.

> (Fixed and enumerations would
> still require generics, although I suspect most people would simply convert
> fixed to float for output rather than worrying about an instantiation.)

It would be interesting to play with the ways of constructing 
enumeration and fixed point classes. Both have static parameters, e.g. 
list of names in the case of enumeration. There might be a way achieve 
static polyphormism without going full generic but also without turning 
the language into a C++ templates mess!

> That
> would make a library simple to use, and few people would think that
> something builr-in is needed.

Absolutely. Ideally, everything must go into libraries.

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

Re: Parameterised 'Image Attributes

[Stephen Davies]

On Tuesday, 22 August 2023 at 09:13:50 UTC+1, Dmitry A. Kazakov wrote:
> Nobody loves the syntax T'Image (X) or X'Image! Give programmers X.Image 
> and [<path-of-package-names-nobody-remembers>].Image (X) and they will 
> forget about the attribute.

I have no issue with the 'Image syntax.

Perhaps the formatting parameters could be restricted to T'Image(X) and
not available for X'Image? Or, maybe the language should just add
'Trim_Image and 'Trim_Width and leave the advanced formatting to a
library.

Actually, I think it might also be nice if Float'Trim_Image(X) returned
a string that only used exponential notation for very large or very
small values (which seems to be the default behaviour in Python).
Different names would then be needed (Tidy_Image and Tidy_Width?).

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-23 12:20, Stephen Davies wrote:

> Actually, I think it might also be nice if Float'Trim_Image(X) returned
> a string that only used exponential notation for very large or very
> small values (which seems to be the default behaviour in Python).

To use the shortest representation for the given precision unless 
specified otherwise:

    http://www.dmitry-kazakov.de/ada/strings_edit.htm#6

Ada 'Image attributes have "typographic quality" in plain contradiction 
to the claim being for debugging purpose. That is why the plus sign is 
always represented by a space and why floating-point representation is 
always selected even for exact zero and the way the exponent part is 
formatted. The typographic idea is to have *same looking* output. Note, 
even if the output is mathematically incorrect as in the case of 
floating-point numbers. 'Image considers precision and accuracy same, 
which is *always* wrong when dealing with floating-point numbers.

> Different names would then be needed (Tidy_Image and Tidy_Width?).

It takes several parameters to control the behavior in a reasonable way.

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

Re: Parameterised 'Image Attributes

[Stephen Davies]

On Wednesday, 23 August 2023 at 17:16:12 UTC+1, Dmitry A. Kazakov wrote:
> On 2023-08-23 12:20, Stephen Davies wrote: 
> 
> > Actually, I think it might also be nice if Float'Trim_Image(X) returned 
> > a string that only used exponential notation for very large or very 
> > small values (which seems to be the default behaviour in Python).
> To use the shortest representation for the given precision unless 
> specified otherwise: 
> 
> http://www.dmitry-kazakov.de/ada/strings_edit.htm#6 
> 
> Ada 'Image attributes have "typographic quality" in plain contradiction 
> to the claim being for debugging purpose. That is why the plus sign is 
> always represented by a space and why floating-point representation is 
> always selected even for exact zero and the way the exponent part is 
> formatted. The typographic idea is to have *same looking* output. Note, 
> even if the output is mathematically incorrect as in the case of 
> floating-point numbers. 'Image considers precision and accuracy same, 
> which is *always* wrong when dealing with floating-point numbers.
> > Different names would then be needed (Tidy_Image and Tidy_Width?).
> It takes several parameters to control the behavior in a reasonable way.
> -- 
How about an attribute called something like User_Image
where programmers should make no assumption about the
generated strings and implementations can provide
OS-specific ways to customise things like leading
space/plus/neither, decimal separator character, digit
grouping character/spacing, exponential notation, enum
casing, etc.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-24 21:59, Stephen Davies wrote:
> On Wednesday, 23 August 2023 at 17:16:12 UTC+1, Dmitry A. Kazakov wrote:
>> On 2023-08-23 12:20, Stephen Davies wrote:
>>
>>> Actually, I think it might also be nice if Float'Trim_Image(X) returned
>>> a string that only used exponential notation for very large or very
>>> small values (which seems to be the default behaviour in Python).
>> To use the shortest representation for the given precision unless
>> specified otherwise:
>>
>> http://www.dmitry-kazakov.de/ada/strings_edit.htm#6
>>
>> Ada 'Image attributes have "typographic quality" in plain contradiction
>> to the claim being for debugging purpose. That is why the plus sign is
>> always represented by a space and why floating-point representation is
>> always selected even for exact zero and the way the exponent part is
>> formatted. The typographic idea is to have *same looking* output. Note,
>> even if the output is mathematically incorrect as in the case of
>> floating-point numbers. 'Image considers precision and accuracy same,
>> which is *always* wrong when dealing with floating-point numbers.
>>> Different names would then be needed (Tidy_Image and Tidy_Width?).
>> It takes several parameters to control the behavior in a reasonable way.
>> -- 
> How about an attribute called something like User_Image
> where programmers should make no assumption about the
> generated strings and implementations can provide
> OS-specific ways to customise things like leading
> space/plus/neither, decimal separator character, digit
> grouping character/spacing, exponential notation, enum
> casing, etc.

How anything can be implemented without making assumptions = specifications?

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

Re: Parameterised 'Image Attributes

[Stephen Davies]

On Friday, 25 August 2023 at 08:26:08 UTC+1, Dmitry A. Kazakov wrote:
> On 2023-08-24 21:59, Stephen Davies wrote: 
> > How about an attribute called something like User_Image 
> > where programmers should make no assumption about the 
> > generated strings and implementations can provide 
> > OS-specific ways to customise things like leading 
> > space/plus/neither, decimal separator character, digit 
> > grouping character/spacing, exponential notation, enum 
> > casing, etc.
> How anything can be implemented without making assumptions = specifications?
The reason that the existing 'Image cannot be changed is that it would
break existing software that replies upon knowledge about the generated
string, e.g. Integer'Image(Year)(2..5).
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)

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

On 2023-08-25 11:04, Stephen Davies wrote:
> On Friday, 25 August 2023 at 08:26:08 UTC+1, Dmitry A. Kazakov wrote:
>> On 2023-08-24 21:59, Stephen Davies wrote:
>>> How about an attribute called something like User_Image
>>> where programmers should make no assumption about the
>>> generated strings and implementations can provide
>>> OS-specific ways to customise things like leading
>>> space/plus/neither, decimal separator character, digit
>>> grouping character/spacing, exponential notation, enum
>>> casing, etc.
>> How anything can be implemented without making assumptions = specifications?
> The reason that the existing 'Image cannot be changed is that it would
> break existing software that replies upon knowledge about the generated
> string, e.g. Integer'Image(Year)(2..5).

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.

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

Re: Parameterised 'Image Attributes

[Stephen Davies]

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.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

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

Re: Parameterised 'Image Attributes

[Stephen Davies]

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.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

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

Re: Parameterised 'Image Attributes

[G.B.]

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.

Re: Parameterised 'Image Attributes

[Niklas Holsti]

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.

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

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

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

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

Re: Parameterised 'Image Attributes

[Randy Brukardt]

"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. 

Re: Parameterised 'Image Attributes

[Dmitry A. Kazakov]

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

Re: Parameterised 'Image Attributes

[Rod Kay]

    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.

Re: Parameterised 'Image Attributes

[Vadim Godunko]

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

Re: Parameterised 'Image Attributes

[Rod Kay]

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.