Re: End_Of_File but not really

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

"Steve" <nospam_steved94@comcast.net> wrote in message
news:4-adnQeuHcj3DubYnZ2dnUVZ_oOonZ2d@comcast.com...
>
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:oJednfF3KqVVLOXYnZ2dnUVZ_q-dnZ2d@megapath.net...
> [snip]
> >
> > 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.
>
> Actually... couldn't the "Form" option that is passed to Open include an
> option that changes the end of file behavior?  That wouldn't break old
code,
> but would make new code easier.

I suppose, but it wouldn't help much, because there is no "Form" for
Standard_Input (it's already open). So the behavior of that can't be
changed -- but that's where the worst problem is. So it's not clear that a
new "Form" would be very useful (remember that the default behavior would
still have to be the "bad" behavior).

It's also clear that the bad behavior is inevitable with the current model
of terminators. So we'd need a new underlying model, which sounds like a
mess. Besides, getting programmers comfortable with using exceptions is a
good thing: I/O can fail in many ways other than reaching the end, it's
hardly sensible to write any I/O without some handlers. So I'd be more
inclined to make the End_of_File function Obsolescent - it's much like the
Constrained attribute and specific Suppress (which are already Obsolescent):
it seems like they should work, but they don't.

Net result: it's probably not worth the headache.

                        Randy.