comp.lang.ada
 help / color / mirror / Atom feed
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Get_Line problem (GNAT bug?)
Date: Fri, 8 Dec 2006 10:11:15 +0100
Date: 2006-12-08T10:09:35+01:00	[thread overview]
Message-ID: <18v5cbvzvfow6.1buy2642zkahr.dlg@40tude.net> (raw)
In-Reply-To: wccfybrtj5h.fsf@shell01.TheWorld.com

On Thu, 07 Dec 2006 17:50:50 -0500, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> No. It is the concept, which is broken. And that wasn't Ada, who broke it,
>> but crippled operating systems like Windows and Unix. In a proper OS the
>> line terminator is not a character.
> 
> Why do you say so?  The concept of "sequence of characters", which
> includes blanks and end-of-line chars, seems pretty good to me.
> (Other control chars, such as tabs, should be banished to the far
> side of the moon.)

The concept of a sequence of characters is OK, but it is not text I/O. It
is just String. What I mean is that text I/O cannot be defined in such
terms. If we did that, we would implicitly specify a certain encoding
format, which is OS/presentation specific. It would be OK if there were
only one OS and only one presentation format. But, to give an extreme
example, a text in HTML format should be readable using Text_IO without
seeing any <BR> tags.

> I think the Unix idea -- "line terminator (or separator?) = a particular
> character" -- is a pretty convenient model.  It's certainly convenient
> for parsing input text: read one char at a time, and deal with it,
> treating end-of-line as one possible case.  E.g., an Ada compiler
> typically works that way.

I don't think so. From the compiler construction perspective this
presentation format is very unfortunate, because you don't know in advance
how long a source line is. (Ada program validity depends on line ends.)
Further areas where this idea works quite poorly are networking (there is
no native way to block packets), keyboard input. It is were all these
buffer overrun issues are rooted. And in general it leads to nowhere. What
about EOF character? What about "abs", "declare", "loop" etc characters?
(:-))

> How much human intellectual effort has been wasted by having to deal
> with "text mode" versus "binary mode" ftp?!  The unix model makes them
> identical, and if all operating systems had magically agreed on that
> from the dawn of time, we'd all be better off.

Absolutely, that is exactly my point. It is the flawed Unix model which
considers texts, executables, databases and mouse buttons as sequences of
characters. It is untyped. They should be different ADTs! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de



  parent reply	other threads:[~2006-12-08  9:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-06 14:25 Get_Line problem (GNAT bug?) Maciej Sobczak
2006-12-06 18:06 ` Adam Beneschan
2006-12-06 20:34 ` Gautier
2006-12-06 21:47 ` Dmitry A. Kazakov
2006-12-06 23:40   ` Adam Beneschan
2006-12-07  0:02     ` Björn Persson
2006-12-07  1:09       ` Adam Beneschan
2006-12-07  1:28         ` Björn Persson
2006-12-07  5:00         ` Jeffrey R. Carter
2006-12-07  8:26   ` Maciej Sobczak
2006-12-07  9:21     ` Jean-Pierre Rosen
2006-12-07 13:35       ` Ludovic Brenta
2006-12-07 22:23       ` Robert A Duff
2006-12-07 10:22     ` Dmitry A. Kazakov
2006-12-07 14:51       ` Maciej Sobczak
2006-12-07 16:29         ` Dmitry A. Kazakov
2006-12-08  8:22           ` Maciej Sobczak
2006-12-07 22:50       ` Robert A Duff
2006-12-08  0:13         ` Randy Brukardt
2006-12-08  4:04         ` Larry Kilgallen
2006-12-08  9:11         ` Dmitry A. Kazakov [this message]
2006-12-07  9:14   ` Jean-Pierre Rosen
2006-12-07  3:34 ` Steve
2006-12-07 17:42   ` Adam Beneschan
2006-12-07 22:35     ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox