Re: Text_IO, was: Re: Something I don't understand

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-02-19 23:46 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> I disagree, but then I don't understand how Robert would make C's
>> template idea type-safe -- might Robert expand on his ideas?
> 
> Most people call me "Bob".  Yeah, I know my "From:" line say "Robert".  ;-)

Apologies. I did remember your preference, but only after clicking
"Send" :-(

> My answer depends on if (or how much) I'm allowed to change Ada's type
> system.  I've done this in pure standard Ada.  Something like:
> 
>     type Template is new String;
>     procedure Put(T: Template; X1, X2, X3, X4, X5, X6, X7, X8: String := "");
> 
> Put("There were \1 warnings and \2 errors.\n",
>     Image(Warning_Count), Image(Error_Count));
> 
> prints the template as is to standard output, except it replaces \1 with
> X1, and \2 with X2, and the "\n" is new-line.  You can have multi-line
> templates.  "\\" represents "\".
> 
> Note my use of X1...X8 to simulate C's variable-length parameter
> lists.  This is a kludge.

That is where I think this breaks down for current Ada. To really add
this to Ada, you need variable-length parameter lists, or the ability to
aggregate strings of various lengths into a vector of strings.

> Note that Template is a different type from String.  This prevents
> a bug that can happen in C, where you say printf(blah), and blah
> is some data read off the internet.  That can be a security hole!

But Template objects can still be variable, so they can still be
constructed at run-time from external data (say, some application
configuration file). Or do you intend to define Template as a type that
forbids variable objects and allows only static constants?

But even with variable Templates, this is clearly less risky than the
case in C, where AIUI the risk comes from malicious type breaking where
the format conversion character misuses the corresponding parameter.
That cannot happen in your proposal because all parameters are Strings
and there are no format conversion characters in the Template.

> The user is responsible for writing suitable Image functions
> for their data types, and they can take whatever formatting
> parameters you like.  This seems much more readable than C's
> way of encoding the field widths and whatnot in the template.

Yes indeed, I agree fully with that.

> For localization/internationalization, you can have a table
> mapping "There were \1 warnings and \2 errors.\n" to the
> corresponding template in (say) French.  Different languages
> have different word orders, so you might have:
> 
>     "... \2 ... \1 ... \n"
> 
> to reverse the order of insertion.

So here the templates would be run-time variable, according to the
locale, and not compile-time constants?

I have little experience of multi-language output, but I have not been
impressed by the tools and methods I've seen. I think it is another
problem and won't be solved by such simple template-based tricks.

> This is all 100% type safe.  Most of the checking is static.
> It checks at run time that the number of \1, \2, \3, ... escapes
> matches the number of non-empty Xn parameters passed.

Why should only non-empty Xn be counted? I think it must be permitted
for some Xn to be empty, without this meaning "end of the Xn list", but
just making the corresponding escape produce an empty output string. But
ok, this is a consequence of the kludge with a fixed number of Xn
parameters in the profile.

> Now, if you let me change Ada,

Apart from the type-safe variable-length parameter lists, you mean? ;-)

> I'd allow user-defined literals.
> Any type derived from the Has_Literals interface allows
> literal syntax, and it overrides the Literal_Value function
> to convert the sequence of characters to that type.

Not a bad idea. Would only string literals qualify, not character or
numeric ones? To avoid ambiguities, this should be forbidden for any
type that already allows string literals, right?

But this is beginning to look a bit like C++ parametrized constructors,
called implicitly... slippery slope?

> Template would no longer need to be derived from String; it
> could be a private extension of Has_Literals, and the Literal_Value
> function could "precompile" the template into some convenient/efficient
> internal form.
> 
> The Literal_Value call is evaluated at compile time, so the
> above-mentioned run-time check can now be static.

If the Template is defined by a literal, yes. But I assume Templates
could still be variable objects, too, forcing a run-time check.

> Change the types of the Xn parameters to Has_Image'Class,
> so you can pass Warning_Count, and it automatically dispatches
> to Image(Warning_Count). If you want to use extra formatting
> options you'd call your own Image function explicitly.

But then you get a parameter list which mixes Has_Image'Class and
Strings from Image functions. Or do you mean that String is in
Has_Image'Class, with an Image function that is the identity function?
That would work... sneaky!

> Integer types are derived from Has_Image, and the Image function
> is not an attribute, and (most importantly of all! ;-))
> it doesn't insert an annoying extra blank.

I second that change to the Image function. That is, omit the extra blank.

> I'd also allow variable-length argument lists and/or arrays of strings.

Do you mean polymorphic variable-length parameter lists? Or only lists
that are declared as monomorphic using some 'Class, such as Has_Image'Class?

>> I think that the present method of concatenating strings or using
>> several Puts is good; 
> 
> I think Put (at least to standard output/error) should be task safe.
> That is, it should be atomic with respect to other tasks doing Put.
> Puts from different tasks would be interspersed, but you wouldn't
> get character-by-character interspersal, and you certainly wouldn't
> get the Ada rule ("erroneous and therefore unpredictable behavior").

Hmm yes. I don't know the history behind the non-task-safe choice.
Perhaps there was a fear of unnecessary distributed overhead for
non-tasking programs on operating systems where the OS I/O system is not
task safe.

> That rules out the "series of Puts" method.  You need to build up
> your whole message (possibly multi-line) and then Put it in one
> fell swoop.

Yes, certainly, if you have multiple tasks which output to the same device.

> The concatenating strings method just looks ugly to me -- I can't easily
> see what the message is going to look like.  With a template, I see
> the whole message, with marks for where variable data is inserted.

I can understand this feeling, but the template method has its own
ugliness -- the need for escapes and the need to count and match up
escapes with parameters to understand what text will replace each escape.

> It is odd that in Ada, 'Image doesn't support the same formatting
> control as Text_IO.

Yes indeed.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .