🚀 go-pugleaf

In article <814@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>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.
>
[Lots of examples deleted]

This argumentation seems a little doubtful to me.  I don't have
experience with all the systems RAO'K mentions, but (to the best of my
memory) I have never seen a use of end-of-file from the terminal that
wasn't being used to pretend that the terminal was more than one file.

Cases in point:

DEC-10 Prolog (on TOPS-20, alas):
	User says [user], gives clauses and ends with ^Z.  The system
	pretends that there is a file 'user' by reading from the
	terminal until end-of-file is seen.  As far as Prolog is
	concerned the file ended at that point, and no more reading
	is done from that particular file at that point.

Using the terminal as standard input in Unix:
	Example: user types 'cat >foo' and then writes contents of file
	on terminal, indicating end by end-of-file.  As far as the
	reader of that particular input is concerned the file ended at
	that point, and no more reading is done from that particular
	'file'.

In conclusion:  I think that software conventions concerning
end-of-file from the terminal exist primarily to enable the
system/user to pretend that the terminal is more than one file.  In
fact, I know of no instance where this is not so.  Can somebody come
up with an example where multiple end-of-files are actually used in
one single ('conceptual') file?

-- 
Gunnar Blomberg, ZYX, +46 8 6653205, grzm@zyx.se