🚀 go-pugleaf

In article <443@ecrcvax.UUCP> bruno@ecrcvax.UUCP (Bruno Poterie) writes:
>While reading the input-output section of the latest BSI standard proposal
>for built-in predicates [Draft 4, PS/201, IST/5/15 Prolog, June 87], I read
>something which caused my blood to boil:
>
>	(page 28, section 12.3) ... read/1 - input a term
>
>	read(Term) reads the next term from the current input stream and
>	unifies it with Term. The input term must be followed by a period
>	followed by a space, tab, carriage return, line feed or end of file.
>	If end of file has been reached than read(Term) fails.
>
>  [deleted]
>
>	WHO WOULD SERIOUSLY WANT END-OF-FILE CAUSE read/1 TO FAIL ???
>

I think this is a much better semantics than returning "end_of_file".
If you want an input predicate that succeeds on end-of-file, you can
simply define:

		input(term(T)) :- read(T), !.
		input(end_of_file).

This has the advantage that it tags the returned value, so your program
won't break even if the clause "end_of_file." occurs in the middle of
the file (yes, I have actually seen this happen).
The proposed semantics also makes it easy to write forward loops:

		treat_file(F) :- see(F), loop, seen.

		loop :- read(T), treat_term(T), !, loop.
		loop.

In my experience, this kind of file processing is more common than
failure-driven loops.

However, failing on syntax error does not seem to be a good idea.
End-of-file is something that all file-processing programs must be
able to handle since most files have finite length, but syntax error
indicates that something is wrong: maybe an operator declaration was
forgotten, or the wrong file was opened. This is clearly an error that
should activate a debugger (or a break loop, or something equivalent),
so the user may be given a chance to correct the mistake before the
program proceeds.
-- 
Bjorn Danielsson, ZYX Sweden AB, +46 (8) 665 32 05, bd@zyx.SE