Path: utzoo!mnetor!uunet!husc6!think!ames!sri-spam!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: <828@cresswell.quintus.UUCP>
Date: 28 Mar 88 08:30:19 GMT
References: <608> <1197@kulcs.kulcs.uucp> <783@cresswell.quintus.UUCP> <2411@zyx.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 92
Keywords: get0 read end_of_file BSI

In article <2411@zyx.UUCP>, grzm@zyx.UUCP (Gunnar Blomberg) writes:
> 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.

> 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.

> 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.

Wrong.  Dec-10 Prolog does **NOT** think the file ended at that point.
compile(user), consult(user), break, or anything which uses the usual
consult loop will stop.  But it will stop because it has seen 'end_of_file',
not because it thinks the file has ended.  Those loops don't do any more
reading because they DON'T do any more reading, not because they CAN'T.
Here is a transcript:

	| ?- read(A), read(B), read(C), read(D), read(E).
	|: this-is-a.
	|: ^Z
	|: this-is-c.
	|: ^Z
	|: ^Z
	A = this-is-a,
	B = D = E = end_of_file,
	C = this-is-c 

> 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.

This may be misleading:  the effect is of NESTED files, not of a
sequence of files.  (In fact if you want, you can even interleave
several input streams from a terminal, each stream getting its own
end-of-file.)

Blomberg seems to suggest that by saying that the possibility of multiple
end-of-file conditions is to permit multiple user of the terminal, he
has shown that it is not important to preserve this behaviour.  I hope
that I have misunderstood him.

(1) I took some pains in my previous message to point out that it is not
    only terminals which can experience multiple end-of-file conditions.
    {Think for a moment about doing BSD-style non-blocking I/O in Prolog.
    Why _not_?}  And I specifically mentioned 'user'.  Even in the case
    of terminals, this behaviour can be obtained with _any_ (real or
    pseudo-) "terminal", not just 'user'.

(2) Nested "files" on a terminal are something one uses many times a day.
    Think about break/0 and debugging.

(3) "I don't use it" is not good justification for "it should go".
    I don't use ancestral cuts.  Is that any sort of justification for
    saying they should not be in the language?  No way!  I do say it,
    but I need much better evidence than that:  I had to show how you
    could write a Prolog interpreter without them, and I had to find
    arguments to show that ancestral cuts were bad in themselves.

Before we get into further debate about multiple end-of-file conditions
I should do a better job of explaining why I raised the point.  The
ability to 'consult(user)' and to 'break' is very useful for debugging.
Having read/1 and get0/1 return an end-of-file marker when the operating
system indicates end-of-file is a coherent convention which additionally
makes this use of the terminal very easy, without requiring special
conventions for resetting the state of the terminal stream.  (You get
nested data streams from 'user' without having to open new streams.)
It did not appear from what few sparse minutes there are that the BSI
committee had ever considered this.  I claim that this is existing
practice in "Edinburgh Prolog" (the BSI definition of which is "what
Clocksin & Mellish say"), and that extraordinarily good reasons are needed
to warrant a change in existing practice, and that those reasons have not
yet been explained.  Further, I pointed out the possibility of multiple
end-of-file conditions to show that the claim that it is easy to simulate
existing practice using the fail-at-end approach is a false claim.

I do not claim that returning an end-marker at the end is the only sensible
thing to do in all circumstances, nor that a Prolog standard should mandate
ALS-Prolog behaviour only.  Whoever it was who suggested that it should be
possible to get an end-marker, a failure, or an error, was clearly right.
Who could object to a standard which made it easier for Prolog users to
get their existing code running?