Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: behavior of read/get0 at end_of_file
Message-ID: <814@cresswell.quintus.UUCP>
Date: 24 Mar 88 08:58:35 GMT
References: 608 <1197@kulcs.kulcs.uucp> <783@cresswell.quintus.UUCP> <787@cresswell.quintus.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 65
Keywords: get0 read end_of_file BSI

Just to continue with the get0 topic:

	The fail-at-end approach rests on an assumption
	which deserves to be made explicit, because it is false.

What is the assumption?   That receiving the end-of-file indication from
an operating system indicates that there is nothing further to read in
that stream.  This is false?  Yes.

Let's ignore 4.2BSD sockets, V.3 Streams, non-blocking I/O, VMS
concatenated files, and other esoterica which one doesn't expect
BSI Prolog to cope with.  Let's just consider terminals.

In Tops-10 (home of DEC-10 Prolog):
	end-of-file from the terminal is a software convention (^Z).
	You can just keep reading from the terminal after that, and
	in fact that's exactly what DEC-10 Prolog does.

In UNIX (original home of C Prolog):
	end-of-file from the terminal is a software convention
	(EOF character typed after an empty line).
	You can just keep reading from the terminal after that, and
	in fact that's exactly what C Prolog does.

In VM/CMS, using SAS Lattice C
	end-of-file from the terminal is a software convention
	(some magic string, which defaults to "EOF", but it is
	trivially easy for a program to change it -- use afreopen()).
	I believe that you can keep reading from the terminal after
	that, but I haven't tried it myself.

On a Macintosh, using ALS Prolog
	end-of-file from a window is a software convention
	(you click on "End of File" in the "Edit" menu).
	All windows and streams remain live after that, and
	you can just keep reading, and that's what ALS Prolog does.

On a Xerox Lisp Machine, using Xerox Quintus Prolog
	end-of-file from a TEXEC window is a software convention.
	All windows and streams remain live after that, and
	you can just keep reading, and that's what XQP does.

[The sample of Prologs is not of interest here; my point is that there
 are several *operating systems* with this characteristic.
]
So the rule actually followed in Edinburgh-compatible Prologs is that
    -   the sequence of characters codes returned by get0/1 is
	the sequence of characters delivered by the source
    -   with the end-of-file marker inserted every time the
	host indicated the end-of-file condition
    -	Prolog receives through get0/1 as many characters and as many
	end-of-file markers as there are; any attempt to read past the
	end of this union stream is an error.  Not a failure, an error.

It happens that when you are reading from disc files, most operating
systems will indicate the end of file condition once.

Are terminals the only kind of file for which multiple end-of-file
conditions are plausible?  No.  The convention for tapes is that a
single tape-mark (usually reported as an end-of-file condition) is
merely a separator; a tape as such is terminated by a double tape-mark.
Thus a Prolog program copying one tape to another (this is a reason why
we might want put(-1) NOT to close a file; if it does anything special
on a tape it should be to write a tape-mark) might want to keep reading
after seeing an end-marker.