🚀 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