bruno@ecrcvax.UUCP (Bruno Poterie) (10/22/87)
References: [line-eater] 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. Possible calls and errors. (a) The syntax of the input term must agree with current operator declarations. Otherwise, an error message is printed and the call fails. Examples. ..... ..... read(T) current input stream is: foo 123. and there is no prefix operator declaration for foo. The call aborts and a syntax error message is printed. First point: what may well occurs on a syntax error not caused by an operator? Second point: either the call fail or it aborts on an operator error, but not both! And having it abort the call means that any syntax error would force a direct return to the top-level ??? even inside consult ??? And, above all, third point: WHO WOULD SERIOUSLY WANT END-OF-FILE CAUSE read/1 TO FAIL ??? How then could we write loop such as: treat_file(F) :- see(F), repeat, read(T), treat_term(T), T = end_of_file, !, seen. when the two most famous such loops are the top-level and consult ??? How would you then distinguish between a syntax error and an end-of-file if the syntax error caused a fail ??? If, i say if, it was possible to define a standard error catching mechanism, a la setjmp/longjmp (C), or a la catch/throw (Lisp), or a la exception/raise (Ada), or whichever mechanism you like (although i have myself quite precise ideas about this subject), then, of course, we could admit that END-OF-FILE would raise/throw/longjmp a predefined error/event/exception, for which the user could define where and when it wants any exception/catch/setjmp he wants to cope localy with ... BUT... we don't have this standard. Or, if there where something like: eof(Stream) defined in the standard, we could at least manage to test before reading. BUT .. Anyway, can we really afford to redefine so much algorithms, and rewritte so much code, a lot of it being (Prolog) system code, just for the sake of a 'desire to change'? I know that there are several terms returned by read/1 on end of file: 'eof', 'end_of_file', ?-(end), etc... but, wouldn't it be simpler to try to standardise one of them? So Please, Please, you people of this BSI comittee, think again before it is too late! No implementer concerned with the users needs would ever implement such a semantic! We don't need a dead-born standard! ================================================================================ 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 ================================================================================
bd@zyx.UUCP (Bjorn Danielsson) (10/28/87)
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