• Parameterised 'Image Attributes

    From Rod Kay@21:1/5 to All on Fri Aug 18 17:18:29 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luke A. Guest@21:1/5 to Rod Kay on Fri Aug 18 09:25:44 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to Rod Kay on Fri Aug 18 11:53:44 2023
    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 */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J-P. Rosen@21:1/5 to All on Sat Aug 19 11:14:34 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to J-P. Rosen on Sat Aug 19 12:03:09 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J-P. Rosen@21:1/5 to All on Sat Aug 19 13:56:14 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luke A. Guest@21:1/5 to Dmitry A. Kazakov on Sat Aug 19 12:45:41 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to J-P. Rosen on Sat Aug 19 15:01:36 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to J-P. Rosen on Sat Aug 19 17:27:25 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From moi@21:1/5 to J-P. Rosen on Sat Aug 19 17:49:41 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.B.@21:1/5 to Jeffrey R.Carter on Sun Aug 20 09:53:11 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to moi on Sun Aug 20 02:25:20 2023
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to G.B. on Sun Aug 20 11:27:47 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Randy Brukardt on Sun Aug 20 11:43:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Dmitry A. Kazakov on Mon Aug 21 18:11:19 2023
    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


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Dmitry A. Kazakov on Mon Aug 21 18:37:43 2023
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Dmitry A. Kazakov on Mon Aug 21 18:34:55 2023
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Randy Brukardt on Tue Aug 22 10:13:47 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Randy Brukardt on Tue Aug 22 09:38:38 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Davies@21:1/5 to Dmitry A. Kazakov on Wed Aug 23 03:20:07 2023
    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?).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Stephen Davies on Wed Aug 23 18:16:10 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Davies@21:1/5 to Dmitry A. Kazakov on Thu Aug 24 12:59:37 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Stephen Davies on Fri Aug 25 09:26:07 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Davies@21:1/5 to Dmitry A. Kazakov on Fri Aug 25 02:04:41 2023
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Stephen Davies on Fri Aug 25 15:02:58 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Davies@21:1/5 to Dmitry A. Kazakov on Mon Aug 28 02:18:37 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Stephen Davies on Mon Aug 28 12:58:23 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Davies@21:1/5 to Dmitry A. Kazakov on Mon Aug 28 08:42:39 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Stephen Davies on Mon Aug 28 18:09:03 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niklas Holsti@21:1/5 to Dmitry A. Kazakov on Mon Aug 28 20:58:13 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From G.B.@21:1/5 to Dmitry A. Kazakov on Mon Aug 28 19:33:51 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Niklas Holsti on Mon Aug 28 21:08:10 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to G.B. on Mon Aug 28 21:08:16 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Dmitry A. Kazakov on Wed Sep 6 20:04:00 2023
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dmitry A. Kazakov@21:1/5 to Randy Brukardt on Thu Sep 7 11:01:58 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rod Kay@21:1/5 to All on Sat Sep 23 20:00:26 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vadim Godunko@21:1/5 to Rod Kay on Mon Sep 25 22:47:17 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rod Kay@21:1/5 to Vadim Godunko on Tue Sep 26 20:15:44 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)