Path: utzoo!mnetor!uunet!mcvax!enea!zyx!grzm
From: grzm@zyx.UUCP (Gunnar Blomberg)
Newsgroups: comp.lang.prolog
Subject: Re: behavior of read/get0 at end_of_file
Message-ID: <2410@zyx.UUCP>
Date: 25 Mar 88 12:17:31 GMT
Reply-To: grzm@zyx.SE (Gunnar Blomberg)
Organization: ZYX Sweden AB, Stockholm, Sweden
Lines: 44
Keywords: get0 read end_of_file BSI


Hmm...  isn't this a lot of fuss about very little?

It seems to me that whatever semantics is chosen, it is simple to get
the other:

BSIread(X) :-
   DEC10read(X),
   X \== end_of_file.

DEC10read(X) :-
   BSIread(Y),
   !,
   X = Y.
DEC10read(end_of_file).

Given that most Prologs seem to use the DEC-10 Prolog approach, and
that it is probably marginally more efficient to write BSIread in
terms of DEC10read than the other way around, the DEC-10 approach seems
the obvious choice.  Not that I think the other choice is all that
much worse...  Isn't it more interesting to discuss things where it is
harder to get it the way one wants (like the question raised by
Richard O'Keefe about whether a string data-type is necessary, or even
useful.  Now *that* is interesting!)

----------
At this point I had a discussion with a colleague of mine, and it
turns out that it isn't this simple.  In fact, I now believe that it
is impossible to get the BSIread functionality from a system that only
provides the DEC-10 one.  The predicate BSIread above will fail if the
file read contains 'end_of_file', of course.  This (for me) tips the
balance over in favor of the BSI approach.  It is after all easy to
write DEC10read in terms of BSIread.

Naturally there should be a provision for compatibility with "old"
programs.  I would be quite happy to name BSIread read_term, for
instance, and provide a user-level predicate read, that could be
redefined to give the required semantics.

-----------
As far as get0 goes, the question is much easier, since there *is* an
obvious out-of-band value, namely -1.
-- 
Gunnar Blomberg, ZYX, +46 8 6653205, grzm@zyx.se