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: 
 backlog2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
Newsgroups: comp.lang.ada
Subject: Re: Text_IO, was: Re: Something I don't understand
Date: Tue, 18 Feb 2014 00:50:23 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <lduaof$alu$1@dont-email.me>
References: <4a3e55f6-9f54-4084-9f37-96efd4b0d349@googlegroups.com>
 <ad687a22-84c1-4c7d-bf8d-023fda30d849@googlegroups.com>
 <e7a5d697-12d1-4150-b713-3ce1156f158d@googlegroups.com>
 <0b358700-871b-4603-addd-65e07c7d59e5@googlegroups.com>
 <wcc1tz3al9l.fsf@shell01.TheWorld.com> <ldpv63$vc0$1@dont-email.me>
 <wcca9drdoc3.fsf@shell01.TheWorld.com> <ldt0m5$2ad$1@dont-email.me>
 <bmetfvFp5prU1@mid.individual.net> <ldtjgk$o98$1@dont-email.me>
 <bmf9btFrpu3U1@mid.individual.net>
Injection-Date: Tue, 18 Feb 2014 00:50:23 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="e458ff8b81bc0c159989eb0e36c6e372";
 logging-data="10942"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX19SRNEgVMMRGCdAYk9AGmYXBqKtLnjGnrA="
User-Agent: slrn/0.9.8.1 (VMS/Multinet)
Cancel-Lock: sha1:r//AijWLLFKmivcHPsFtOLN0Rp4=
Xref: number.nntp.dca.giganews.com comp.lang.ada:184953
Date: 2014-02-18T00:50:23+00:00
List-Id: <comp.lang.ada>

On 2014-02-17, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> 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.
>

That could be caught at compilation time because there would be a
mismatch between the format string and the number of variables.

>
> 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.
>

I see your point, but it's still better than what the C language itself
provides and it is guaranteed to catch type mismatches even if it's
deferred to runtime.

I wonder if it's possible to do something along the lines of gcc
which looks at the printf format string during compilation and
complains, during compilation, if there's a mismatch detected in
data types.

I am interested to see what Robert's detailed proposals look like or
what any other ideas for printf style template I/O might look like.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world