for S'Image use Func??
in [ADA]
|
Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Dmitry A. Kazakov on 11 May 2010 10:24 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 11 May 2010 10:27 "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 11 May 2010 11:03 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 11 May 2010 11:23 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 11 May 2010 11:45
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 |