Re: Get_Line problem (GNAT bug?)

[Maciej Sobczak <no.spam@no.spam.com>]

Dmitry A. Kazakov wrote:

>>> When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests
>>> the end of the current line or both the line end and the file end.
>> I understand. But then I consider the specs to be broken, see below. :-)
> 
> 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.

That's a brave concept. ;-)
Why do you assign the special meaning to the line terminator? Is it 
*that* special in, for example, your previous post? Why not assign the 
special meaning to word or sentence terminator? Or anything else for 
that matter. Isn't it domain-specific? Do you want support from "proper 
OS" for all this stuff?

>>> 1. Never ever use End_Of_File with text files;
>> This is broken. For me, End_Of_File is a concept that is completely 
>> orthogonal to what the file contains and how it is interpreted.
> 
> Right, so see above. You need a file system which has EOF state
> determinable without look ahead.

No. I might be using pipes or fifos or sockets or whatever else where 
EOF is not really determinable by position. It's not file system issue.

> [Though I don't defend End_Of_File. I would simply remove it from Text_IO.]

But then it would be somewhere else. There would be an opportunity to 
specify it correctly, without messing with interpretation of the file 
structure.

>> It is true that it is defined in Text_IO and therefore it might be a 
>> hint that actually EOF is somehow entangled with interpretation of text 
>> markers, but that's not what I would expect.
> 
> Huh, what did you expect buying Windows? (:-))

I don't understand this - Windows is not involved in this discussion at 
all (not mentioning buying it).

>>> 2. If you yet use End_Of_File then do it for *each* character of the file;
>> I don't see how it might solve this problem - End_Of_File would block 
>> after first <CR> anyway.
> 
> Yes, but then at least you would know what's going on. End_Of_File happened
> to be lower level (in OSI hierarchy terms) than Get_Line.

This is exactly what I would expect. End_Of_File should not mess with 
file structure.

> Mixing levels is
> asking for trouble.

Agreed.

>>> 3. As Adam has suggested, End_Error exception is the right design;
>> I don't find it to be "right". For me, exception is something that is 
>> unexpected. An error, usually. [...]
> 
> OK, this is a bit "theological" issue... (:-))

Indeed. :-)

> My answer is no. Exception is not an error. It indicates an exceptional
> state. Note that an exceptional state is a *valid* state. While an error
> (bug) has no corresponding program state at all.

It's not about bugs. I have presented an example of truncated XML file - 
there's no bug in a program that happened to be given a broken file to 
digest. It's an error in a sense that the program cannot read the data 
that it genuinely expects. Still, the program should handle this case 
reasonably, so we have valid state.

Now, if the program specs says: "read the lines from input until EOF", 
then this for me immediately translates into a loop with some exit 
condition. A while loop, probably, or something in this area. "Read 
until" - you have a regular end-of-sequence condition here. Close to 
iterators. How do you write iteration routines? Do you use exceptions 
for the end-of-sequence condition to break the loop? In what way 
iteration over the container is different from reading lines from input?

(Probably the best thing would be to just have "line iterators".)

Sorry, I'm not convinced that exception might be a correct design choice 
for breaking the loop that reads data from well formatted file.

> This is because you consider it from the C++ stand point.

Which is, of course, evil by definition. ;-)

> In Ada exceptions
> are efficient.

So how do you write iteration routines?

> They are highly recommended for use in place of return
> codes.

Good point. There is no return code here. Everything is managed at the 
same level. The red-light here is that with exceptions I would need to 
use empty "where" clause. Empty clause at the same level? Looks like 
goto in disguise.

> End_Of_File in your program serves the
> purpose of return code.

Nope. It's the end-of-sequence condition. Just like with iterators.

> What is even worse, from the software design
> perspective, is that one operation "give me next line" is split into two,
> so that the side effect of one determines the outcome of another and
> reverse.

Same with iterators.

> It is a very fragile (and wrong) design. Just notice how much
> efforts it requires to analyse.

Frankly, I don't find it difficult. Ada is very readable, you know. ;-)

> And what for? To defend a myth, that each
> loop should have only one exit?

If the specs says "read until end", then this means single exit 
condition to me.

> Your code didn't managed that either!

Why?

> Neither manages it inputs longer than 99 characters.

Good point. How should I solve this?

> Do you call it clean?

Yes.

> Further, even in C you wouldn't use it either.

You're right, I wouldn't. Why would I use C if C++ gets it right? ;-)

string line;
while (getline(cin, line))
{
     // play with line here
}


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/