Prev: I/O streaming with custom data transport
Next: ANNOUNCE: Avatox 1.4 now available
From: Maciej Sobczak on 7 Dec 2006 03:26
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. :-)

> The rules of thumb I suppose I and many other Ada programmers are using:
>
> 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.
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.

> 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.

> 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. With files, EOF happens - on average -
almost once per file and it is something that I expect. There is nothing
unusual in the fact that there is no more data in a file, *unless* in
the given environment we really want to work with conceptually infinite
data sources. But this is an exception (no pun intended) and is rather
domain-specific, so should not be imposed by the general-purpose library.

EOF might be an error if, for example, with some known file format the
parser expected some more data and there isn't any (like with the XML
file which was truncated somewhere in the middle). *That* would be the
reason to raise an exception, but then it's the business of the parser,
not IO library. The library should not interfere with my interpretation
of what I want to see in the file.

> 4. End_Error is not only cleaner and correct, but also more efficient.

It's not cleaner for me (see above), it is very likely correct (in the
sense that the real solution is broken) and I don't see on what basis it
is expected to be more efficient. :-)

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
From: Jean-Pierre Rosen on 7 Dec 2006 04:14
Dmitry A. Kazakov a �crit :
> The rules of thumb I suppose I and many other Ada programmers are using:
>
> 1. Never ever use End_Of_File with text files;
> 2. If you yet use End_Of_File then do it for *each* character of the file;
> 3. As Adam has suggested, End_Error exception is the right design;
> 4. End_Error is not only cleaner and correct, but also more efficient.
>
And I'll add another one:
5. End_Error works correctly with badly formed files, i.e. files whose
last line does not end with and end-of-line mark. You can get strange
behaviour in that case with any other solution.

--
---------------------------------------------------------
J-P. Rosen (rosen(a)adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
From: Jean-Pierre Rosen on 7 Dec 2006 04:21
Maciej Sobczak a �crit :
>> 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.
I beg to differ. Otherwise, they would be called "errors" or "abnormal".
An exception corresponds to an "exceptional" event, i.e. something that
prevents usual processing, and forces you to an exceptional handling. If
you consider that normal processing (normally the body of a loop) is the
rule, it is an exception to the rule. And EOF certainly matches this
definition (as is an error, of course, but it is not the only case).

Exceptions are a useful tool in the programmers tool box. The narrow
view of exceptions as just a way to handle errors is a mistake that
prevents elegant solutions to some problems, in my view, and I've been
constantly fighting against that.
--
---------------------------------------------------------
J-P. Rosen (rosen(a)adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
From: Dmitry A. Kazakov on 7 Dec 2006 05:22
On Thu, 07 Dec 2006 09:26:07 +0100, Maciej Sobczak wrote:

> 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.

>> The rules of thumb I suppose I and many other Ada programmers are using:
>>
>> 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. It is not language business.

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

> 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? (:-))

>> 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. Mixing levels is
asking for trouble. Because End_Of_File drags you into a character-oriented
encoding issues, so have to face this in arms.

>> 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... (:-))

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.

Sure an exception may indicate an error, but this error is *never* one of
the program where it is handled. For example, Segmentation Fault is an
error of an application, but a valid state for the OS which has spawned
that erroneous application and where Segmentation Fault is handled.

To summarize: we should distinguish errors (and states) of the problem and
solution spaces. Exceptions live in the latter, what you meant does in the
former.

>> 4. End_Error is not only cleaner and correct, but also more efficient.
>
> It's not cleaner for me (see above), it is very likely correct (in the
> sense that the real solution is broken) and I don't see on what basis it
> is expected to be more efficient. :-)

This is because you consider it from the C++ stand point. In Ada exceptions
are efficient. They are highly recommended for use in place of return
codes. This is a *good* design. End_Of_File in your program serves the
purpose of return code. 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. It is a very fragile (and wrong) design. Just notice how much
efforts it requires to analyse. And what for? To defend a myth, that each
loop should have only one exit? Your code didn't managed that either!
Neither manages it inputs longer than 99 characters. Do you call it clean?
Further, even in C you wouldn't use it either. You probably would turn to
fgetc (or even to fread):

int Char;
// Do we all know that characters are integers? char is just for fun,
// real programmers are using int for all datatypes! (:-))

while (EOF != (Char = fgetc (File)))
{
...
}

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Ludovic Brenta on 7 Dec 2006 08:35
Jean-Pierre Rosen <rosen(a)adalog.fr> writes:
> I beg to differ. Otherwise, they would be called "errors" or "abnormal".
> An exception corresponds to an "exceptional" event, i.e. something
> that prevents usual processing, and forces you to an exceptional
> handling. If you consider that normal processing (normally the body of
> a loop) is the rule, it is an exception to the rule. And EOF certainly
> matches this definition (as is an error, of course, but it is not the
> only case).
>
> Exceptions are a useful tool in the programmers tool box. The narrow
> view of exceptions as just a way to handle errors is a mistake that
> prevents elegant solutions to some problems, in my view, and I've been
> constantly fighting against that.

I agree with you in the general case where you have an Ada run-time
library that propagates exceptions. But there are cases where your
Ada run-time library does not propagate exceptions, or where you don't
have a run-time library at all. In those particular cases, you have
to use the "narrow view" whereby an exception is something so
exceptional that it "should never happen" (tm).

In the OP's case, handling EOF as an exception is just fine, since
file I/O implies the existence of a suitable run-time library.

--
Ludovic Brenta.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: I/O streaming with custom data transport
Next: ANNOUNCE: Avatox 1.4 now available