Re: End_Of_File but not really

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:1165597373.375204.16280@l12g2000cwl.googlegroups.com...
> Randy Brukardt wrote:
> > "Adam Beneschan" <adam@irvine.com> wrote in message
> > news:1165514423.562024.70510@j72g2000cwa.googlegroups.com...
> > ...
> > > (2) This behavior is what the RM requires.  To me, this means the RM
is
> > > broken---it just doesn't make sense to me that End_Of_File would
return
> > > True if there is more information in the file to get with Get_Line
> > > (even if the information is "the presence of a blank line").  But
> > > perhaps it's my own understanding that is broken; perhaps my
> > > understanding of what End_Of_File is supposed to do is wrong, even
> > > though I think it's what a reasonable person would expect a function
> > > called "End_Of_File" to do.
> >
> > This is exactly the state. It's the way these things were defined in Ada
83,
> > and required by the ACATS since the very begining. I'd be very surprised
if
> > you found any Ada compiler that doesn't have this behavior (didn't you
try
> > it on your compiler to cross-check)?
>
> > As I noted before, there is absoletely no chance that this behavior (or
any
> > behavior of Text_IO) would be changed, because there's no possible way
for
> > such a change to the compatible. If the program "knows" about the "lost"
> > blank line, it might fail badly if the definition was to be changed. So
it's
> > 23 years too late to fix Text_IO.
>
> OK, this is the sort of clarification I was looking for.  I was under
> the impression that, since the definitions of the terminators were left
> up to the implementation, it would be possible for an implementation to
> define them in a way so that things would work "correctly" (i.e. in a
> way that would make sense to me).  But I guess that's not possible, or
> in any case implementations aren't expected to do this.  Thanks.

No, it's not possible. That's because of the definition of writing files.

Recall that closing a file adds (logical) line and page terminators before
the file terminator if they are not present. Let's show these terminators as
<EOL><EOP><EOF> (the real representation doesn't matter).

Now consider the program:
    Create (File1, ....);
    Close (File1);

File1 will contain just <EOL><EOP><EOF> after this program.

Now consider the similar program:
   Create (File2, ...);
   New_Line (File2);
   Close (File2);

File 2 will *also* contain just <EOL><EOP><EOF>.

But clearly, when you re-read these two files, you'd expect different
behavior. The first should return End_of_File = True immediately and raise
End_Error if you call Get_Line, and the second should return End_of_File =
False and allow a single call to Get_Line. But these files have the exact
same contents! There is no possible way for them to have different behavior,
even though they're clearly different from a user perspective.

It appears that Ada 83 chose End_of_File = True and a single call to
Get_Line to work in order that the most important feature of each of these
files works as expected. (That is, if the last line of a file that you write
is a blank line, you can read a blank line; and that a Get(char) following
End_of_File = False will always work.) But the result of that is that
neither file will read quite as expected! IMHO, it would have been better to
define End_of_File such that a subsequent Get_Line would always raise
End_Error (it does mean that for Get(char)). But such hindsight is 20-20.

Since these two files are identical to the language, and certainly the ACATS
could check that they're considered identical (it makes similar checks, I
don't know if this exact one is made), no amount of implementor tricks can
make things work sensibly. In our implementation, the two files would indeed
have different contents (the first would be empty and the second would have
an explict <CR><LF> [or just <LF>, depending on the target]}. But that
doesn't help, because we have to consider them logically the same, since the
language does -- indeed, it makes it more complex than simply writing out
all of the markers. (Depending on all of the markers to be present would
make Text_IO useless on files written by something other than Ada, which
would be unusuable even if it is technically correct.)

                                      Randy.