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

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

On Wed, 19 Feb 2014 23:45:47 +0200, Niklas Holsti wrote:

> On 14-02-19 16:13 , Dmitry A. Kazakov wrote:
>> On Wed, 19 Feb 2014 15:20:18 +0200, Niklas Holsti wrote:
>> 
>>> On 14-02-19 11:40 , Dmitry A. Kazakov wrote:
>>>> On Wed, 19 Feb 2014 10:36:29 +0200, Niklas Holsti wrote:
>>>>
>>>>> On 14-02-18 11:31 , Dmitry A. Kazakov wrote:
>>>>>> On Tue, 18 Feb 2014 11:00:44 +0200, Niklas Holsti wrote:
>>>>
>>>>>> To me text buffer, stream, file, string are all instances of the class of
>>>>>> types over which Put dispatches. OK, we can call the abstract root type of
>>>>>> the class "Text."
>>>
>>> My notion of type "Text" is an internal representation of text meant for
>>> human reading and viewing. I don't see any logical need for making this
>>> type a class; there would be only one predefined (and private) type.
>> 
>> Class is needed because there must be more than one implementation of the
>> interface
> 
> Why? It is not expected that there should be more than one
> implementation, in the same Ada program, of Ada.Containers.Vectors, for
> example.

Ada.Containers.Vectors is generic and suffers same issues as Text_IO.

How are you going to handle encoding using single implementation?

> The "Text" type I am talking about is kind of a container for structured
> text ("text" as in meaning (2) below).

What are you going to do when

1. the structure does not match?

2. the content itself varies?

>> and because the interface itself need to be extended in order to
>> have Ada library implementations of reasonable size and complexity.
> 
> That does not convince me. Mere volume (e.g. number of operations) is
> not, to me, a reason for splitting a coherent interface into different
> packages.

It is not the number but ability to add new unknown to language designers
operations.

>>> (2) a text meant only for human reading/viewing and therefore to be
>>> rendered as nicely and readably as the chosen viewing device allows.
>>> That some parts of the text can be seen as sequences of characters is
>>> secondary, and the specific characters and their sequence can change
>>> according to the rendering.
>> 
>> Rendered text is a text so long the reader can reconstruct (1) from (2). So
>> in effect (1) and (2) are equivalent in the sense that both are (1).
> 
> No, text (2) is *not* the result of rendering text (1). Text (2) is
> logically structured text (probably some kind of tree) that has been
> deliberately constructed to have structure.

Whatever. It can have hyperlinks, embedded video and casual games in it.
How are you going to pack this into the RM? How do you find a consensus
what belong to text and what does not? It is just bad design.

> To make it very concrete: under Windows you use Notepad to create text
> (1), but MS-Word to create text (2).

And I dispatch to Notepad, Word, GPS, and other implementations of text
processing and text formats, while it is all text to me.
 
>>> Ada.Text_IO implements mainly (1), with some basic support for
>>> typewriter-style formatting (column spacing, line spacing, page tracking).
>>>
>>> The "Text" type I am talking about aims to be the internal
>>> representation of (2), before rendering on some viewing device.
>> 
>> Why should anybody care about (2)?
> 
> Because users want to see nicely formatted output,

That alone does not justify the architecture of the text formatting library
you propose. It could if you demonstrated that other architectures are
unable to produce nicely formatted output. But they are well capable of. 

But my question was about the internal representations of a certain narrow
subclass of texts you propose to be the universal description of all texts
Ada should support.

>> Why Text_IO should have anything to do with (1)?
> 
> Text (1) can also be processed with Sequential_IO, but usually text (1)
> is divided into syntactical, meaningful tokens, such as keywords or
> decimal numbers, and Text_IO provides (rudimentary) facilities for
> generating such tokens on output, and lexically scanning and evaluating
> such tokens on input.

That is not a property of text. It is of a container of objects of assorted
types.

> The situation is the same in other programming languages, which all
> provide such token-oriented input-output for text (1) files. For example
> printf/scanf in C.

Sequential text processing is not what text is. Nobody argues against
sequential processing, though there are cases where it is not sequential
(e.g. syntax highlighting). But that has little to do with viewing a text
as a sequence of lines or pages or paragraphs etc. Furthermore, there is no
single preferred view of a text medium. Some application might wish to view
it as lines, like compiler do, others might prefer other views. This is why
a class is needed to decouple views from formatting actions and the medium.

>>>> This was attempted before, many many times, actually. From PostScript to
>>>> HTML, an intermediate language that would take care of separating higher
>>>> level formatting from lower level rendering. It never worked how many times
>>>> tried.
>>>
>>> Uh... surely PostScript and HTML "work". I'm pretty sure that a large
>>> fraction, perhaps even a majority of programs today generate most of
>>> their human-readable output as HTML.
>> 
>> Which is why quality of text is so miserable and why the modern OS makes a
>> i486 out of whatever many cores, gigahertz and terabytes monster you run it
>> on.
> 
> You are changing the issue from "works" to "needs a lot of resources and
> is misused". So you lose the argument :-)

But we agreed on the point about resources. So what justifies the orgy?
Ease of use? HTML is very poor on that. Safety? HTML is a joke regarding
it. Maintainability? etc.

>> And of course generating HTML or parsing it is no way simpler than
>> traditional formatting in any sense of that.
> 
> What do you mean by "traditional formatting"?

Without an intermediate layer.

How

   Put (File, "&");

is better than

   Put (File, ''');

?

> I'm not suggesting that the Ada programer would write code to generate
> HTML. The Ada programmer's code would create a "Text" (i.e. a text (2)),
> which can be output as HTML, if it is emitted to a device/file/channel
> which wants HTML.

To put it simple, you don't want HTML. But that was the point I made, HTML
does not work as a middleman. Yet you want to introduce one of your own
hoping it would work better than HTML. It will not.

> I'm not suggesting that Text_IO should be removed. Of course Ada
> programs must be able to read and write files of text (1). It may even
> be desirable to extend the token-level formatting abilities of Text_IO
> or the Image functions, either by more parameters or by templates or
> pictures.

So Text_IO remains a mess, and we add more mess to it.

> But my main point is that if our goal is text formatted to modern
> standards of appearance (with proportional fonts et cetera) then the
> rendering cannot be made token by token, or Put (item) by Put (item);
> the renderer must work on a whole text (2).

It is not "modern", it is simply bad. Bad standards existed in the past and
will appear in the future. It is not Ada's concern, IMO.

>>> If the need is to generate nicely formatted
>>> output, rendered in device-specific ways, and typewriter formatting is
>>> not enough, what is the alternative?
>> 
>> I don't understand the question. It is not about alternatives, the
>> formatting must be done. It is about decomposition of the task into
>> software components. I don't want any middlemen especially such that in
>> order of magnitude more complex than direct formatting.
> 
> Can you give an example of what you mean by "direct formatting"?

Without intermediate objects representing items sufficiently larger than
the things being processed. I want keep formatting "imperative", if you
will.

>> syntax highlighting, WYSIWYG text processing etc.
> 
> If you are talking about interactive applications, at most a screenful
> of text is shown at a time, therefore Text_IO overheads would be
> insignificant.

The design you propose, as you are replacing local operations with ones
dealing with the text as a whole.

> But I think that this kind of application would not use
> Text_IO anyway, because the formatting capabilities of Text_IO would not
> be sufficient.

See? That is because of monolithic design putting imaginary requirements
ahead. This is a wrong way.

>>> I don't see any need for converting a File/Stream *into* Text, unless
>>> the File/Stream is a serialized representation of the full internal
>>> structure of a Text object, in which case the File/Stream structure is
>>> private and normal serialization/deserialization methods apply.
>> 
>> But your proposal was:
>> 
>>    procedure Get (From : in out Text; Value : out Integer);
>>    procedure Get (From : in out File_Type; Item : out Text);
> 
> No, I proposed Put operations, not Get operations. "Text" (that is, text
> (2)) is meant only for output, not for input. For input, use text (1).

Only Text_O? No Text_I at all?

>>> I don't intend that the type "Text" should be so fancy and complete that
>>> it could be used as such to implement an advanced word processor.
>>> Following the same rationale as Ada.Containers, "Text" should provide as
>>> much functionality as can be expected to be useful for (and used by)
>>> many Ada programs and programmers, but programmers requiring high
>>> performance or high/specific functionality would have to implement more
>>> advanced "text" representations themselves.
>> 
>> And so you need it extensible, ergo, a class.
> 
> Not so, if we accept the same rationale as for Ada.Containers: they are
> meant for use in applications without extreme or special demands on the
> performance of the containers.

Ada container library was wrong design from the start. But that is another
story for another day.

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