Path: utzoo!mnetor!uunet!mcvax!unido!ecrcvax!bruno
From: bruno@ecrcvax.UUCP (Bruno Poterie)
Newsgroups: comp.lang.prolog
Subject: Re: behavior of read/get0 at end_of_file
Message-ID: <519@ecrcvax.UUCP>
Date: 22 Mar 88 16:55:39 GMT
References: <608> <1197@kulcs.kulcs.uucp> <783@cresswell.quintus.UUCP> <518@ecrcvax.UUCP>
Reply-To: bruno@ecrcvax.UUCP (Bruno Poterie)
Organization: ECRC, Munich 81, West Germany
Lines: 66
Keywords: get0 read end_of_file

I do not think that having read/1 returning an atom on EOF is a bad thing.
If you take as an example certain UN*X tools, they read their input from
a file (typically stdin) until finding a line composed of a single dot.
So it is perfectly legal to submit a file which contains a dot-line in the
middle if you want only the first part to be feeded to the tool. Same thing
for Prolog, if you have a huge file full of various facts but want only say
the first 100 to be used as input in your test program, then simply add
the EOF mark before line 101. I would then prefer to have it as a directive:
		...
		:- eof.

so that it is not a bare fact but actually a command to the consulting tool
that it have to EOF this input source. It is then coherent with other
directives like:
		...
		:- [file3,file4].
		...
which actually order the consulting tool to insert at this point the content
of the named files. I believe that the notation "eof" is quite standard in
the UN*X system and already in some Prolog, including as a test predicate for
this very term:
		... read(Term), eof(Term) -> ...

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

	Now for the get0/1 [or get_char/1/2]: having it returning an otherwise
impossible value, say an atom as suggested by Micha, is ok if the returned
thing is an integer representing the ascii code [or ebcdic] of the character.
using the same term as the one returned by read/1, and consequently the same
test predicate as only mechanism to check for EOF, would greatly improve the
compactness and consistency of the i/o system. As a side effect, close/1 is
not strictly necessary anymore as the following sequence does the job:
		eof(EOF), put(EOF)
Because obviously put/1 must handle the same term in the same way (I am afraid
that outputing CHAR modulo 256 would not work in this case).
I nevertheless believe that EOF == -1 is a clearer convention, returning an
object of the same type but out of the normal range of normal input, and
is already the UN*X convention. It would not force put/1 to accept it as EOF
character, as it would be outputed as: -1 modulo 256 (or 512) == 255. Passing
-1 to UN*X putchar() does not generate an EOF!

Ok, enough delirium tremens for today. My main point is: the character i/o
should provide a very low level facility, with no hypothesis about the use
which could be made of them. Using read(Term) and eof(Term) provides an
uniform, simple, elegant and portable mean of performing i/o at Prolog term
level. Using get0/1 implies you are interested in the real bits contained
in your input support, so you want to control it at a low level. Returning
the -1 value is portable and low-level, because independant of ascii or
any other character set. Alternatively, returning eof and using the same
eof(Char) test predicate would be again low-level, portable, and free of
any supposed semantic. More important, most of prolog input loops may be
adapted with this scheme at low cost. Failing at EOF, however, would mean
full rewriting of those applications and system libraries.

================================================================================
  Bruno Poterie		# ... une vie, c'est bien peu, compare' a un chat ...
  ECRC GmbH		#		tel: (49)89/92699-161
  Arabellastrasse 17	#		Tx: 5 216 910
  D-8000 MUNICH 81	#		mcvax!unido!ecrcvax!bruno
  West Germany		#		bruno%ecrcvax.UUCP@Germany.CSNET
================================================================================