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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin.stu.neva.ru!bolzen.all.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Text_IO, was: Re: Something I don't understand Date: Mon, 17 Feb 2014 22:22:22 +0200 Organization: Tidorum Ltd Message-ID: References: <4a3e55f6-9f54-4084-9f37-96efd4b0d349@googlegroups.com> <0b358700-871b-4603-addd-65e07c7d59e5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net qrF8a9GhoMtls8u54mL6hgd2x+Oc7qKpBanZTWHa9JNsjuL7hE Cancel-Lock: sha1:zSX/TP600wXzfYNXfvbHF2vhKl8= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-Original-Bytes: 4806 Xref: number.nntp.dca.giganews.com comp.lang.ada:184949 Date: 2014-02-17T22:22:22+02:00 List-Id: On 14-02-17 20:13 , Simon Clubley wrote: > On 2014-02-17, Niklas Holsti wrote: >> On 14-02-17 14:52 , Simon Clubley wrote: >>> On 2014-02-16, Robert A Duff wrote: >> [snip] >>>> A simplified and type-safe version of C's printf style >>>> (template-based) formatting would be more readable than >>>> concatenating a bunch of strings together to print messages, >>>> and MUCH better than using a series of Put calls to print >>>> a single message. >>>> >>> >>> _Totally_ agree with this. >> >> I disagree, but then I don't understand how Robert would make C's >> template idea type-safe -- might Robert expand on his ideas? >> > > Oh, I can see a way in which it can be made fully type safe. > > Assume that support for internal to external conversions is implemented > within the type itself as Robert suggests. Ok. So the type comes with some predefined (perhaps overridable) "Image" function that takes a value of the type and some kind of format specification. > Furthermore, assume, as I suggested, that you need to pass a format > parameter to the type in order for the value to be formatted as required. Ok. > The Ada version of printf would iterate over the combined format string > and pass the fragment of it intended for the formatting of the current > variable to the variable type's Internal_To_External support routine. Ok, but yuck... Why collect all the format "fragments" for all ther variables into one string, which then has to be picked apart again? According to some convoluted and at the same time limited syntax-embedded-in-the-string, such as the C "%" stropping. This invites errors in matching the fragments in the format string with the variables in the variable sequence, just as in current template-based systems e.g. C. You add a variable, but forget to add the format fragment, et cetera. With the current method using string concatenation, the format parameters are automatically associated with the right variable, being parameters in the same Image call. > If the passed format fragment was compatible with the data type, the > Internal_To_External routine would process the format and return the > formatted string back to the Ada version of printf so it can be added > into the output buffer. In other words, effectively the same as the current string concatenation method, but with added formatting parameters to the Image functions. Except that the current method fits in the normal Ada expression syntax and semantics, but your proposal would be something special, requiring a variable-length list of variables to be output, like C varargs. > If, OTOH, the format fragment was incompatible with the data type, the > Internal_To_External support routine within the type would raise a > exception. So this is only *dynamically* type safe, not statically so. Moreover, as C formats already demonstrate, sooner or later one will run out of useful and unique letters and format forms, so a format fragment meant for variable X, of type T, may by mistake be applied to variable Y, of type S -- and will happen to be valid for that type, too, but will not produced the desired result. > And voila, C printf templates in a fully Ada type safe manner. No, dynamic type safety is not fully "Ada type safe". Ada is (mainly) statically type safe; dynamism only enters in subtype safety. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .