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).
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).
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.
On 2023-08-19 11:14, J-P. Rosen wrote:The vast majority of Ada users ignore a number of useful features
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.
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...
Le 19/08/2023 à 12:03, Dmitry A. Kazakov a écrit :
On 2023-08-19 11:14, J-P. Rosen wrote:The vast majority of Ada users ignore a number of useful features
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...
provided by the language, and keep asking for improvements that are
already there...
Yes, put has nothing to do with 'Image. Yes, put requires instantiation.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.
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?
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.
Le 18/08/2023 à 10:25, Luke A. Guest a écrit :
On 18/08/2023 08:18, Rod Kay wrote:The intent of the 'Image attribute is to have a quick representation,
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.
mainly for debugging purposes. If you want nice formatted output, use
the Put procedure on String from Text_IO.
On 2023-08-19 11:14, J-P. Rosen wrote:for all types.
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
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 doso, 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 andfloating-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 asit 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 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:The intent of the 'Image attribute is to have a quick representation,
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.
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.
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, ...
Additionally, one ends up with a magic mechanism that only the compiler can use. That *never* is a good idea.
Attributes do not allow named parameters outside a few special cases, and *never* allow reordering of parameters. Does that need to change, too?
'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).
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
Of course it must be generic, which kills all fun.
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?
"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.
"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.)
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.
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:How about an attribute called something like User_Image
Actually, I think it might also be nice if Float'Trim_Image(X) returnedTo use the shortest representation for the given precision unless
a string that only used exponential notation for very large or very
small values (which seems to be the default behaviour in Python).
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.
--
On Wednesday, 23 August 2023 at 17:16:12 UTC+1, Dmitry A. Kazakov wrote:
On 2023-08-23 12:20, Stephen Davies wrote:How about an attribute called something like User_Image
Actually, I think it might also be nice if Float'Trim_Image(X) returnedTo use the shortest representation for the given precision unless
a string that only used exponential notation for very large or very
small values (which seems to be the default behaviour in Python).
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.
--
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:The reason that the existing 'Image cannot be changed is that it would
How about an attribute called something like User_ImageHow anything can be implemented without making assumptions = specifications?
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 Friday, 25 August 2023 at 08:26:08 UTC+1, Dmitry A. Kazakov wrote:
On 2023-08-24 21:59, Stephen Davies wrote:The reason that the existing 'Image cannot be changed is that it would
How about an attribute called something like User_ImageHow anything can be implemented without making assumptions = specifications?
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.
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:I did read Randy's response, he explained the difficulty in adding
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 stringThis will be rejected on the same grounds as the original proposal.
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)
Read Randy's response.
I did read Randy's response, he explained the difficulty in adding
parameters to 'Image,
so I suggested an alternative parameter-less
attribute. You could allow the output of this attribute to be
configurable by either some package data (c.f. Text_IO.Default_Width)
and/or by the OS. To be honest, all I really want is an attribute that
any Ada program can use to get a string suitable for output to its
users, i.e no leading space and exponentiation only used when needed.
On 2023-08-28 11:18, Stephen Davies wrote:
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! (:-))
On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
On 2023-08-28 11:18, Stephen Davies wrote:
This will not happen either. But here I would agree, it is clearly a
case of language littering.
Littering, schmittering, how about adding Bin_Image, Oct_Image & Hex_Image for Ints and Dec_Image for Ints & Reals ;-)
However see the GNAT-specific 'Img attribute. For debugging purposes it
does not add space where 'Image also for debugging purposes adds! (:-))
Unless this changed recently, 'Img also adds a leading space.
On 2023-08-28 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
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! (:-))
On 2023-08-28 13:58, Dmitry A. Kazakov wrote:
On 2023-08-28 11:18, Stephen Davies wrote:
I did read Randy's response, he explained the difficulty in adding
parameters to 'Image,
He rather explained that this will never happen... (:-))
There is no good reason why attributes should not have the same
parameter syntax as subprograms and entry calls.
Yes in principle, but it is understandble that making this happen now
could impact both the language definition and various implementations in non-trivial ways.
Neither there is one why 'Image must be a non-overridable attribute
In Ada 2022, 'Image is defined to call the new attribute 'Put_Image,
which can be specified (ie. overridden) by the programmer for any type.
See http://www.ada-auth.org/standards/22rm/html/RM-4-10.html.
On 28.08.23 18:09, Dmitry A. Kazakov wrote:
On 2023-08-28 17:42, Stephen Davies wrote:
On Monday, 28 August 2023 at 11:58:24 UTC+1, Dmitry A. Kazakov wrote:
On 2023-08-28 11:18, Stephen Davies wrote:
This will not happen either. But here I would agree, it is clearly a
case of language littering.
Littering, schmittering, how about adding Bin_Image, Oct_Image &
Hex_Image
for Ints and Dec_Image for Ints & Reals ;-)
Bin_Width_1_Image, Dec_Width_4_Image and so on... Cool, make Ada C
again! (:-))
Or maybe leave type attributes alone. Instead, let Ada.Streams
have I/O manipulating setters.
Then, in order to preserve the meaning of "corresponding S'Output"
(LRM 13.13.2) for every S'Input, add AI to the Ada run-time system.
On 2023-08-28 11:18, Stephen Davies wrote:
Neither there is one why 'Image must be a non-overridable attribute
"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).
I've been using 'Gnat.formatted_Output' which I've found quite
useful. Unfortunately, it seems to be a little buggy with its formatting.
On Saturday, September 23, 2023 at 1:59:20 PM UTC+4, Rod Kay wrote:
I've been using 'Gnat.formatted_Output' which I've found quite
useful. Unfortunately, it seems to be a little buggy with its formatting.
You can take a look at VSS's Virtual_String_Templates and Formatters, see
https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-templates.ads
https://github.com/AdaCore/VSS/blob/master/source/text/vss-strings-formatters.ads
and an example of its use
https://github.com/AdaCore/gnatdoc/blob/3e94448ac57270caf4b4502f208f78e1d51da2b2/source/gnatdoc-messages.adb#L130
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 355 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 04:07:17 |
| Calls: | 7,656 |
| Calls today: | 8 |
| Files: | 12,812 |
| Messages: | 5,700,746 |