--- On Thu, 9/24/09, Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
So the question is what is most convenient. Returning true means to the idiom 'not(eoln)' has clear meaning: there is something to read.
However, conversely eoln(f) returning true generally means that you can safely read a single character, or readln to position yourself at the next line. Given this current behavior, this is not true when you're at the end of the file. It's telling you that if you read you'll get a space for the end of line character, when in fact you'll get an error because you read past the end of the file.
I buy the hysterical raisins argument, someone may be relying on this non-compliant behavior and changing it would break existing code. But I don't buy the argument that it's needed to protect the meaning of the 'not(eoln)' idiom since by your own admission, eoln shouldn't be checked when you're at the end of the file.
It would be sufficient to simply have options for this behavior I suppose. By default --classic-pascal should report an error and fail in this situation if we are to comply with the ISO standard. The default for other dialects can be determined, and behavior in the default dialect can remain the way it is currently if there are sufficient objections to changing it. But it'd be nice if we could have some way to tell the compiler how to properly deal with eof and eoln and how they interact at compile time, since it's not terribly understandable as it is now.
Thanks, Chad Simmons