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.

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.

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 */

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

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

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.

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

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

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

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.

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

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.

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

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

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" rel="nofollow" target="_blank">http://www.dmitry-kazakov.de/ada/strings_edit.htm#Integer_Edit
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
>

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

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

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

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

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?).

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

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.

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

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)

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