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

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

On 14-02-17 19:17 , Dmitry A. Kazakov wrote:
> On Mon, 17 Feb 2014 18:59:43 +0200, Niklas Holsti wrote:
> 
>> I think that the present method of concatenating strings or using
>> several Puts is good; what is needed is to extend or replace the 'Image
>> attribute with similar value-to-string functions which are more
>> controllable, flexible, and work also for composite types.
> 
> Except that all these need to be MD primitive operations. There is no way
> to solve this without MD.

Why multiple dispatch? Which would be the multiple controlling
parameters? I think only the input value should be controlling; perhaps
you think that the output channel/device should also be controlling?

>> Perhaps
>> something analogous to the stream attributes, but with the ability to
>> control the output format at each invocation, which is not possible with
>> the stream attributes.
> 
> I don't think there is any need in having formats. A few formatting
> parameters could be passed along to Image or equivalent.

Well, parameters and options is what I meant. For example, the ability
to specify blank fill, zero fill, center/left/right alignment, digit
group spacing (1 123 456,00 or 1_123_456.00), etc.

> Environment settings (e.g. locale) should come from the rendering surface
> object. No need to specify them at all. This is how stuff like fonts,
> colors etc is handled in GUI.

A "rendering surface" is not always available at the point where the
string is generated.

There could be a private predefined type for such settings. A value of
that type could be given as a parameter in the Image call to set the
default format (which could then be overridden if the Image call also
has some specific format parameters). A GUI toolkit could have a
function to to return a suitable value of this type from a "rendering
surface" object. I don't see why this, or the output channel, should be
a controlling parameter.

Something like these flexible Image functions already exists in Annex F
(Information Systems), but it is partly template-driven ("picture"-driven).

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