From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Text_IO, was: Re: Something I don't understand Date: Wed, 19 Feb 2014 15:13:59 +0100 Organization: cbb software GmbH Message-ID: <7gb1iv15zuh$.1qbeifwuyvuoa.dlg@40tude.net> References: <4a3e55f6-9f54-4084-9f37-96efd4b0d349@googlegroups.com> <0b358700-871b-4603-addd-65e07c7d59e5@googlegroups.com> <13cmx8lollig2.1ic40x57wows8$.dlg@40tude.net> <1mh0lp04e4bzc.vr6hi3fcbba5.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: I5Na6+WsEzT8WoegI0VZTA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:18667 Date: 2014-02-19T15:13:59+01:00 List-Id: 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 and because the interface itself need to be extended in order to have Ada library implementations of reasonable size and complexity. > By the way, perhaps the word "text" is ambiguous. I think it is time to > make a clear distinction between: > > (1) a text file (sometimes called an "ASCI file"), which is a sequence > of basic symbols (e.g. Character or Wide_Character) used to represent > *data* for either reading by another program, or for human reading > (without formatting), and Sequence of symbols is a string. Text is at least a sequence of strings (lines). > (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). > 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)? Why Text_IO should have anything to do with (1)? One of the issues Text_IO had was inference into text issues (e.g. pages etc). There is nothing wrong with pages except that 80% of formatting and editing does not care about pages. The result is abstraction inversion, and you want to make it only worse. >>> I'm thinking of two levels of "Put": >>> >>> Put (To : in out Text, Item : in String); >>> Add items to a Text, building a logically structured Text, >>> but without rendering it yet. This wil probably need >>> some concept of "points in a Text where more stuff can >>> be inserted" so that the Put can preserve or extend the >>> logical Text structure. >>> >>> Put (To : in out File; Item : in Text); >>> Render the Text into some external File. >>> >>> The Text buffer intermediary means that each level of Put can (if >>> desired) be dispatching on one of the parameters, without needing >>> multiple dispatch. >> >> 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. And of course generating HTML or parsing it is no way simpler than traditional formatting in any sense of that. >> And for sure, it will be even more hated than Text_IO page formatting is, >> because the overhead will be far bigger. Imagine describing the semantics >> of, say, conversion of File, Stream, String to Text and backward. > > Overhead compared to what? Compared to direct dispatch to the implementation tailored for the give medium. Why do I need HTML in order to write a stream or memory string? > 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. > The overheads of Text_IO are important only when processing large text > *data* files (meaning (1) of "text"). For generating human-readable text > (meaning (2)), especially in an interactive context, the overheads are > utterly negligible. It is not completely true. Huge amounts of readable texts are processed without any human intervention. For those Text_IO performance is a big problem: Ada project compilation, syntax highlighting, WYSIWYG text processing etc. > 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); You must create a text object in order to apply type-specific Get operation on it. When you emulate MD through cascaded dispatch, and this is what you are doing, you need temp objects to carry intermediate states. That will be very expensive for I/O, and extremely complicated because I/O is a stateful thing. You will have a hell of coordinating the states of the file and its text proxy. > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de