🚀 go-pugleaf

In article <519@ecrcvax.UUCP>, bruno@ecrcvax.UUCP (Bruno Poterie) writes:
> I believe that the notation "eof" is quite standard in
> the UN*X system and already in some Prolog

I just grepped through the UNIX [UNIX is a trademark of AT&T] manuals,
and all I could find was the function feof(Stream).  None of the UNIX 
utilities I am familiar with uses "eof" to signify end of file.
Franz Lisp does something interesting:
	(ratom [Port [Eof]])
	(read  [Port [Eof]])
	(readc [Port [Eof]])
return the Eof argument (which defaults to nil) when you read the
end of the file, so you can get whatever takes your fancy.

> so i think we could maybe abandon the end_of_file notation of Quintus (sorry
> for you Richard, a compatibility switch could very easily turn it back anyway),

But it ***ISN'T*** a Quintus notation!  This is the notation used by
	DEC-10 Prolog
	EMAS Prolog
	C Prolog
	Quintus Prolog
	Stony Brook Prolog
	ALS Prolog
	Expert Systems International Prolog-2
	AAIS Prolog (in "Edinburgh" mode only)
and doubtless many others.  end_of_file IS the "de facto" standard.
Poterie's suggestions are good ones, but in order to overthrow the
de facto standard, they would have to be MUCH MUCH better, and they
aren't.

> but it is not an important point as the aim would be to discipline one's
> programming style by systematically using the test form: 
> 	eof(Term) 
> and never ever explicit the EOF term itself. Portability is great.

Beware.  While Quintus Prolog offers the library predicate
	is_endfile(?EndMarker)
there are other Prolog systems, such as AAIS Prolog, where there is a
predicate with a similar name which takes a Stream argument:
	is_eof(+Stream)
in AAIS Prolog means "is it the case that Stream is positioned at its end?".
Yes, portability is great, but would it not be more just to reward those
people (such as SICS, Saumya Debray, ALS, and others) who have tried to
provide it, by standardising their solution?

> As a side effect, close/1 is
> not strictly necessary anymore as the following sequence does the job:
> 		eof(EOF), put(EOF)
Um, what about INPUT streams?  And there is another reason for wanting
close/1:  it will close a stream which is not the current output stream.