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

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

On 14-02-17 21:55 , Dmitry A. Kazakov wrote:
> 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.

That could be done using overloading based on the expected type of the
Image function result, instead of multiple dispatch. Of course that
would require different types to represent ASCII strings and UTF8
strings, etc. Using different types for different kinds of strings would
be a good thing anyway, IMO (but I know that this causes problems with a
combinatorial explosion of the number of predefined subprograms
involving strings).

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

Hrm. I'm not at all sure that I would want such different formatting for
different output channels to happen automatically. For one thing, using
superscripts for exponents would prevent or complicate the user's
copy-paste operations, for example copying the output of a Float number
into a calculator accessory.

There should really be a type "Text" that represents text, with all its
complications of encoding, formatting, styles, fonts, lines, paragraphs,
tabulation, indentation, language, ... True, that is horribly complex,
but that's reality now. It is debatable if this should be in the
language, or in toolkits (GUI or others). Probably some core part of it
should be in the language and the rest in a toolkit or in an optional
Annex to the language.

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