From: Dmitry A. Kazakov on
On Tue, 11 May 2010 06:35:39 -0700 (PDT), Maciej Sobczak wrote:

> OK, really - what's exactly being inefficient in buffered input?

You said it, it is buffering.

> What I want is a stream interface to the blobs that my filesystem is
> storing for me, so that I can build higher-level constructs on top of
> it.

But if my file system already has get-line-as-an-array-of-code-points. Why
should I go deeply down to the representation layer, to a stream of octets?

>> The bottom line is, Ada does it right (tm).
>
> If it did it right (tm), I would not have to reinvent
> My_Better.Text_IO.

You should not. The question was about formatting, I/O is OK.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Robert A Duff on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:

> Nobody want to see fixed font output.

> Only if the output is improperly formatted. There is no application for
> fixed point fonts other than for source code of a machine language.

Hmm. Why do you exempt "source code" from your "Nobody..." above?

(I assume by "machine language" you mean "programming language",
not machine language as in ones-and-zeros with op-codes and
all that.)

- Bob
From: Dmitry A. Kazakov on
On Tue, 11 May 2010 10:27:27 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:
>
>> Nobody want to see fixed font output.
>
>> Only if the output is improperly formatted. There is no application for
>> fixed point fonts other than for source code of a machine language.
>
> Hmm. Why do you exempt "source code" from your "Nobody..." above?

I feel it difficult to read sources in proportional font. Maybe I am
getting too old...

> (I assume by "machine language" you mean "programming language",
> not machine language as in ones-and-zeros with op-codes and
> all that.)

Yes.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on
Le Tue, 11 May 2010 10:26:02 +0200, Dmitry A. Kazakov
<mailbox(a)dmitry-kazakov.de> a écrit:
>> But you have no way to know when you've read
>> a empty line in a lexer routine that is reading
>> character by character.
>
> A lexer routine shall never do that. You either read lines and then parse
> them, or else you do stream input and the line end is to be determined by
> the lexer (i.e. by the language being parsed).
With all due respect, really don't agree with that. A lexer is not
required to be line oriented.

--
pragma Asset ? Is that true ? Waaww... great
From: Yannick Duchêne (Hibou57) on
Le Tue, 11 May 2010 17:03:28 +0200, Dmitry A. Kazakov
<mailbox(a)dmitry-kazakov.de> a écrit:

> On Tue, 11 May 2010 10:27:27 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes:
>>
>>> Nobody want to see fixed font output.
>>
>>> Only if the output is improperly formatted. There is no application for
>>> fixed point fonts other than for source code of a machine language.
>>
>> Hmm. Why do you exempt "source code" from your "Nobody..." above?
>
> I feel it difficult to read sources in proportional font. Maybe I am
> getting too old...
A way to try to handle this question may be this one : could their be any
formatting language applicable to typical application source ? This would
require to have two sides, one for the formatting and one for the text.
This would not be applicable, this would clutter the application source
too much.

The only thing which is near to that, is automatic formating (no perfect
by the way). And how it does formatting ? ... with blanks, tabs and new
line. So back to the initial point.

Could the automatic formating tool use other things to render source
layout ? This would require either, again to have the formating language
embedded in the source (not acceptable as suggested above) or to have a
way to link/anchor formating instruction to each part of the source it is
to be applied ; which in turn would require either something embedded in
the language to allow that or some complicated external third files which
would try to keep track of some (many) marks in the source while you edit
it. Not good, ... not portable.

There is still a last other way : editor specific formating. Some do that,
except that it goes wrong as soon as you switch to another editor, and
others are unlikely to use the same editor as yours.

Natural language texts did not have the same requirement, they are “in
flow”. Computer language are not most of time.

This is not a matter of being old or a matter of fashion. There is no real
other way of doing formating with this special kind of texts. Some one
already try to imagine new ways for that, but either failed or just
proposed editor specific formating.

--
pragma Asset ? Is that true ? Waaww... great