🚀 go-pugleaf

In article <10468@uqcspe.cs.uq.oz.au> pjr@cs.uq.oz.au writes:
>
>How does your favourite Prolog behave in the following situation
>
>query:  ?- read(f(X)).
>
>I already know the following:
>
>Nu-Prolog :  
>      continue to input until the input is of the form f(term).
>
>Qu-Prolog & IC-Prolog: 
>      fail - 3 and f(X) don't unify.
>
>LPA MacProlog : 
>      fail - argument of read must be a variable at the time of call.

Oops, this looks like a bug in NU-Prolog.  read/1 should read a single
term (with no backtracking) then attempt to unify it with the argument.

There is a general principle that

	?- pred(...X...), X = Some_term

should behave in the same way as

	?- pred(...Some_term...)

except were this really isn't feasible.  One case where its not feasible
is meta level operations such as write(X) and assert(p(X)).  Here X is
best thought of as a meta level variable rather than an object level
variable and instantiating it gives a different meaning (unfortunately
Prolog doesn't really distinguish between the object and meta levels,
making the meaning of such things less than crystal clear :-).
Another case is where there would be an infinite number of intermediate
answers, such as Y is 1 + X.  If you have coroutining, the thing to do
here is delay the call until X is further instantiated (resulting in the
same behaviour for the two goals).  Without coroutining the best you can
do is trap to an error handler.  However, if you can execute the first
(less instantiated) case sensibly you should always be able to execute
the second case sensibly and you should get the same behaviour.

Is there a case for read/1 returning an error when called with a
non-variable (as in MacProlog)?  I suspect the reason for deciding to
make this an error is that you nearly always call read with a variable
and cases when you don't are most commonly due to mistakes in the
program.  However, this is rather ad hoc.  An implementor may decide to
make division by a negative number an error for the same reason.  It is
easier for everyone if there a a small number of general principles
rather than lots of special cases.  Is there a general principle that
can support the MacProlog behavior?  I think there is, but it requires
the object and meta levels to be distinguished.  When we call read(X), X
should be thought of as a meta variable.  When a meta variable is
compared to another (meta) term, unification is generally *not* the
operation we want but thats what you get with parameter passing in
Prolog.  pred(...Some_term...) should be equivalent to pred(...X...),
meta_equals(X, Some_term).  The exact kind of equality desired is not
clear, but giving an error seems like a better idea than using
unification.

In summary: for simplicity and compatability it should fail, but bear in
mind that Prolog meta level (and I/O) is pretty stuffed from a logical
point of view.

	lee

In article <10468@uqcspe.cs.uq.oz.au>, pjr@cs.uq.oz.au (Peter Robinson (P.J.)) writes:
> How does your favourite Prolog behave in the following situation
> query:  ?- read(f(X)).
> input:  3.

DEC-10 Prolog, C Prolog, Quintus Prolog, &c all fail.

> Nu-Prolog :  
>       continue to input until the input is of the form f(term).

This is a *bug*.  Here's what the on-line manual says:

2?- man read.
read(Term)
read(Stream, Term)
(Non-logical).
Read a NU-Prolog Term, terminated by a period and white space, from the current
input  stream  (or  Stream).   All terms before the first syntactically correct
term are ignored.  If Term contains variables these are distinct from variables
not   in  the  term.   At  end-of-file,  read/1  and  read/2  return  the  atom
end_of_file.  Fails if Term will not unify with the term that is read.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The manual describes the intended behaviour, which is just the same as other
Prolog systems.  Report the error.

I have just fixed the error in my copy of NU Prolog (it's in the file
sys/io.nl, and the error is really obvious).  I've notified the maintainer.

-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.

Three points:
1. Open Prolog misbehaves on this - it succeeds no matter what you input,
but will only bind variables if the term to be read and the term actually
read are unifiable. Clearly most undesirable. Mhust be shome mhistake.

2. In Richard O Keeffe's extract from the NU-Prolog manual, there is a
sentence:
'All terms before the first syntactically correct term are ignored.' What
does that mean?

3. Can anyone remember what DEC10 Prolog did? If memory serves, the
behaviour of get/1 and read/1 were different in this regard.
Can anyone comment?

_________________________
Mike Brady
Computer Science Department, Trinity College Dublin, Ireland

In article <290992115341@brady.cs.tcd.ie> brady@cs.tcd.ie (Michael Brady) writes:
>3. Can anyone remember what DEC10 Prolog did? If memory serves, the
>behaviour of get/1 and read/1 were different in this regard.
Unfortunately I no longer have access to a DEC-10, and the DEC-10
Prolog sources are sitting on a tape that would be a hassle to restore, but
according to the manual and my recollection both read(X) and get(C)
advance the input appropriately and try to unify the object scanned
with their argument. If the unification fails, the advancing of the input
stream is not undone, but the calls fail.

Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
pereira@research.att.com

In article <23753@alice.att.com>, pereira@alice.att.com (Fernando Pereira)
wrote:
[About DEC10 Prolog's behaviour of read/1 and get/1] etc.
 but

> according to the manual and my recollection both read(X) and get(C)
> advance the input appropriately and try to unify the object scanned
> with their argument. If the unification fails, the advancing of the input
> stream is not undone, but the calls fail.

My memory, which could easily be wrong, was that if for read(Term), it read
in the first term it came across, and failed if that term wasn't unifiable
with Term. It would also report syntax errors...
For get0(Char), it read in a character, and if the character didn't unify
with Char, it would advance to the next character and try again, ad
infinitum until the right character was read.
Is my memory playing tricks on me?

The real question is what is the most desirable action in these cases. I
agree with Lee about read/1, but how about get0/1 and get/1?

---------------------
Mike Brady
Computer Science Department, Trinity College Dublin, Ireland

In article <brady-300992144101@brady.cs.tcd.ie> brady@cs.tcd.ie (Michael Brady) writes:

>  For get0(Char), it read in a character, and if the character didn't unify
       ^^^^^^^^^^
>  with Char, it would advance to the next character and try again, ad
>  infinitum until the right character was read.
>  Is my memory playing tricks on me?

Reminds me of skip/1, but my memory is always playing tricks on me.

Alan Newman
--
I use smiley faces all the time, but I usually leave off the mouth. :-)

In article <brady-300992144101@brady.cs.tcd.ie>, brady@cs.tcd.ie (Michael Brady) writes:
> My memory, which could easily be wrong, was that if for read(Term), it read
> in the first term it came across, and failed if that term wasn't unifiable
> with Term. It would also report syntax errors...
> For get0(Char), it read in a character, and if the character didn't unify
> with Char, it would advance to the next character and try again, ad
> infinitum until the right character was read.
> Is my memory playing tricks on me?

Yes.

All the input commands in DEC-10 Prolog had the same behaviour: guessing
wrong about the output argument does not affect which side effects take
place, only whether the query succeeds or fails.

In a mix of Prolog and C:

	get0(Char) :-
		( feof(current_input) -> error
		; Char is getc(current_input),
		).

	get(Char) :-
		( feof(current_input) -> error
		; Temp is getc(current_input),
		  ( Temp =:= EOF ->
		    Char is 26	% in DEC-10 Prolog
		    Char is -1  % in just about every other Prolog since
		  ; isspace(Temp) ->
		    get(Char)
		  ; Char is Temp
		  )
		).

	skip(Char) :-
		C is Char,	% Char may be an expression
		repeat,		% repeat/0 is needed because
		    get0(C),	% get0(C) WON'T skip
		!.

	read(Term) :-
		repeat,
		    get_tokens(Tokens),
		    parse(Tokens, Result),
		!,
		Term = Result.

> The real question is what is the most desirable action in these cases. I
> agree with Lee about read/1, but how about get0/1 and get/1?

They should be compatible with DEC-10 Prolog, C Prolog, PDP-11 Prolog,
Prolog-X, SICStus Prolog, NU Prolog, Quintus Prolog, &c.  It would be best
if the default behaviour was to return -1 for EOF, but a DEC-10 compatibility
mode would be of use as at least once PC implementation still uses 26 for
EOF (because CP/M did, basically).
-- 
RMIT policy requires the use of Gender Inclusive Language in all publications
and in all information conveyed to students, staff, and potential job
applicants.  Lapses into English are the sole responsibility of the author.
The Constitution of Australia does _not_ guarantee Freedom of Speech.