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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 17 Feb 2014 19:42:07 +0200, Niklas Holsti wrote:

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

Print (Display, Shape)

is a textbook example of MD.

> Which would be the multiple controlling
> parameters?

File and Value

> I think only the input value should be controlling; perhaps
> you think that the output channel/device should also be controlling?

Certainly so. Consider ASCII_File, UTF8_File, Gtk_Text_Buffer_Record and so
on. You cannot convert to string before sending it out, because ASCII will
use E for power of 10, UTF8 will use superscript characters for it, and
Gtk_Text_Buffer_Record will do the GTK markup language.
 
>>> 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.

Yes, however, from experience, it quickly gets overcomplicated. I customary
use Input_Parameters and Output_Parameters objects as you suggest below.
They must be controlled as well because you want to be able to extend them.

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

String itself is such a surface. That is the point of having it controlled.
You can replace it with whatever type, e.g. File, Stream etc. And string
itself is a Universe of types because of encodings.

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

Yes of course, but this is usually another set of parameters. Less volatile
parameters, such as whether to use '.' or ',' to introduce fraction belong
to the surface.

> A GUI toolkit could have a
> function to to return a suitable value of this type from a "rendering
> surface" object.

Possible but tedious.

> I don't see why this, or the output channel, should be
> a controlling parameter.

Because you cannot predict all possible combinations of and because it is a
huge wasting of human and computational resources as no given application
will ever use more than 1% of it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de