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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable 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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Text_IO, was: Re: Something I don't understand Date: Wed, 19 Feb 2014 15:20:18 +0200 Organization: Tidorum Ltd Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net blDCYrCNi8CXodtyfoKjfwmOdFuWMdN+TyknoUy1sFmar+i5AA Cancel-Lock: sha1:Fsw0c15SUEAXqB+zGW9Sv6c2EWY= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:18665 Date: 2014-02-19T15:20:18+02:00 List-Id: 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. (There might be some technical reasons for making the type a class, for example with a root type that is low-cost but simple, and some derived classes which provide more functionality but at greater cost. Perhaps the simple root type would be a mandatory language feature, and the derived classes optional features.) 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 (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. 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. >> 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. Even if the final HTML generation is delegated to some web-application framework. > 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? If the need is to generate nicely formatted output, rendered in device-specific ways, and typewriter formatting is not enough, what is the alternative? 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. 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. 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .