From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.216.204 with SMTP id a195mr3832859ywe.6.1438286060822; Thu, 30 Jul 2015 12:54:20 -0700 (PDT) X-Received: by 10.140.98.117 with SMTP id n108mr661644qge.23.1438286060804; Thu, 30 Jul 2015 12:54:20 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!z61no4253612qge.0!news-out.google.com!78ni356qge.1!nntp.google.com!69no2889656qgl.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 30 Jul 2015 12:54:20 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.203.145.32; posting-account=AFCLjAoAAABJAOf_HjgEEEi3ty-lG5m2 NNTP-Posting-Host: 81.203.145.32 References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> <1438244829.17005.26.camel@obry.net> <0a8104af-4ebb-4d82-92e5-6ba7289272ce@googlegroups.com> <262cbf86-25a0-4802-b72e-ec6e650e1dc7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Running a preprocessor from GPS? From: EGarrulo Injection-Date: Thu, 30 Jul 2015 19:54:20 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 3801 X-Received-Body-CRC: 1120451754 Xref: news.eternal-september.org comp.lang.ada:27242 Date: 2015-07-30T12:54:20-07:00 List-Id: On Thursday, July 30, 2015 at 9:27:56 PM UTC+2, Jeffrey R. Carter wrote: > On 07/30/2015 11:51 AM, EGarrulo wrote: > > > > OK. Now please write the code so that it could be easily adapted to a > > different language by possibly swapping the arguments that are fed to the > > output string (this may not cover all existing languages, but it could be good > > enough). I would reimplement Printf to accept a format with positional > > arguments, like "Mr %1 you have won %2 dollars!\n". Then I would define a new > > format string for the alternative output and I would be done. This was > > possible because a solution based on a formatting procedure recognizes that > > output should easily adaptable, something that hard-coded concatenations of > > strings are not. > > Why should I? That's not the problem you presented and I responded to. First a > strawman and now a non-sequitur. Clearly you have no argument. I had already explained in this discussion why I think that the "Printf" solution is preferable: Thanks to its format string, "printf" lets you see at a glance what the output will look like. On the contrary, solutions in Ada -- that involve more than simple string concatenation -- tend to obscure what the final result will look like, and are cumbersome both to write and to read. -- Now, multiply this for all the times that your program needs to print formatted text... Not to mention that the order of the arguments is hard-coded in the valid Ada snippet, whilst you could need a different order to support formatted output in different languages. If I don't repeat my arguments, it is because doing so would be redundant, not because I am playing fancy tricks to win an argument. So... have you got an alternative to propose, or do you agree that "Printf" is a more flexible approach? Before you reply, I am adding that I have already proposed a specification of Printf that takes an array of strings as the arguments to its format string, so that formatting can be done outside, and be customized for new types. Actually, I think that such a function should become standard, because it would integrate well with existing functions (like To_Picture).