🚀 go-pugleaf

In article <2403@zyx.UUCP>, bd@zyx.UUCP (Bjorn Danielsson) writes:
> I can't understand why there should be a "strait-jacket solution" to this
> kind of problem. Why not put in enough flexibility to allow for the most
> obvious cases? In Z-Prolog, (which was never designed to be Edinburgh
> compatible) the "read" predicate can handle end-of-file in three different
> ways, depending on an optional argument:
> 	(1) signal an error,
> 	(2) fail,
> 	(3) return a value supplied by the programmer.
> 
Oh, __HOW__ I wish you were were handling the I/O part of BSI substandard!
That's EXACTLY the right sort of attitude for a standard designer.

I think that there are sound technical reasons for regarding fail-at-end
as a straight-out blunder, and I have used PL/I and Fortran enough to
convince me that end-of-file is NOT an error and shouldn't be treated
like one.  (Reading *past* end-of-file is another matter, which is one of
the things I have against fail-at-end.)  But a more powerful operation,
which is not perceptibly harder to implement, which will let me synthesise
the operation I want, and let BIM synthesize the operation they want,
that's exactly the right thing to do in the standard.

Oddly enough, I had intended to mention Algol 68.  Files in Algol 68 are
rather interesting.  One of the things you can do is say

	FILE example file;
	...
	logical file ended OF example file :=
	    (FILE file parameter) BOOL: (
		# return FALSE to get default action (e.g. error report) #
		# return TRUE to say "corrected, please try again" #
		# or jump out #
	    );

Interlisp does the same sort of thing:

	(WHENCLOSE file 'EOF (FUNCTION (LAMBDA (file) (* action *)) ))

So even if we decide to feed this goose instead of killing it, there are
at least three options:
   1.	specify in each call what action to take on end of file
	read(Stream, Term, EofAction)
	-- This affects 'read' only.

   2.	specify per stream what action to take on end of file
	eof_action(Stream, EofAction)
	-- This could affect any form of input.

   3.	allow both.

One of the constraints which is of interest to Quintus is that whatever the
end of file action is, it has to make sense if the stream was being used by
C or Lisp code.  The nice thing about sticking with -1 as the character
end-of-file mark and adopting option 3 is that it does this.

Note though that as I mentioned in my previous message, just because the
host operating system indicates an end-of-file condition doesn't mean that
it isn't possible to read any more from the file.  (UNIX fans will know
about 'tail -f' and why it is useful...)  The standard should, I said in
'84, include a predicate for testing whether the stream is really ended.
If the stream is not really ended, it should be possible to resume reading.