From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE,
	XPRIO autolearn=ham autolearn_force=no version=3.4.6
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Parameterised 'Image Attributes
Date: Mon, 21 Aug 2023 18:11:19 -0500
Organization: A noiseless patient Spider
Message-ID: <uc0qu4$239o4$1@dont-email.me>
References: <ubn5un$5tvt$1@dont-email.me> <ubn9u8$6fup$1@dont-email.me> <ubq15l$oa8i$1@dont-email.me> <ubqn0t$o3lq$1@dont-email.me> <ubsgp8$19ib8$1@dont-email.me> <ubsmak$1a024$1@dont-email.me>
Injection-Date: Mon, 21 Aug 2023 23:11:01 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="a646227c24097efbc8783f6ec1cd88e1";
	logging-data="2205444"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19h2zaqqIC6z4/b51AfmgYiwsVeucsyu74="
Cancel-Lock: sha1:CF4VoofzKbjNC9xwZECHUE/NDXI=
X-RFC2646: Format=Flowed; Response
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
X-Priority: 3
Xref: news.eternal-september.org comp.lang.ada:65548
List-Id: <comp.lang.ada>

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
>