Re: for S'Image use Func??

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 12 Maj, 17:58, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >> Why an Ada program handling texts need to be aware of your system?
>
> > Because it is running on my system. It's a pretty good idea to have
> > some local awareness.
>
> No, that makes the program non-portable and fragile against system
> modifications.

As I already said, I'm OK with this kind of non-portability.
It does not bother me that my program will not work on non-existing
systems (which effectively includes those obscure systems that you can
surely refer to for the sake of example, but that none of us will ever
use anyway).
I am pragmatic here.

> > Even assuming that I can open some file, the whole "abstraction of a
> > text" is severely limited. I cannot, for example, read the second
> > paragraph of the third chapter of the book that is in the file.
>
> It is necessarily limited here because not every text is a book.

Bingo. So what is a text, really?

Ada.Text_IO (similarly to text I/O libraries in other languages)
focuses on lines. This is similarly outdated as focusing on columns
and really belongs to the same era.
When I read the text in my web browser (the most frequently used
application for text consumption nowadays), the "lines" are whatever
the browser cares to display, which depends on how I scale the window
and what font size I select. I can change these properties dynamically
and in particular nothing prevents me from opening the same document
in several windows, each differently scaled.
This means that "lines" is not a property of the data source, it is a
property of the display.

Yet everybody is dead focused on the concept of text files that are
composed of lines. There are no lines, really.
If "text" means anything more than a stream on steroids, then it must
be recognized to have a much richer structure than just a sequence of
lines. Paragraphs, headings, chapters, whatever - these are structural
elements of text. But not lines. Lines and columns are artifacts of
the teletype printers era - gone long ago.

With this in mind, the "text abstraction" as represented by
Ada.Text_IO is really a stream on steroids. That's why I don't
understand why you put so much stress on distinguish the "text" from
the "stream", while the effective distance between them is close to
zero.

(please don't remind me constantly about filesystems that are based on
records - the line-oriented records are long gone with teletype
printers and nowadays "filesystems" will store whole files in single
records instead, so we are back to streams anyway)

> >> The problem of Text_IO is columns.
>
> > Not only. It cannot detect the end of stream without blocking, for
> > example.
>
> That is a property of the stream. Don't use streams as texts.

Translation: Text_IO cannot detect the end of text without blocking.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4