🚀 go-pugleaf

Sorry if anyone gets this twice - my first attempted followup didn't seem
to work.

In article <3992@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
><Lots of sensible stuff which I agree with completely...>

I just thought I would expand on one point.

Treating predicates as (possibly infinite) tables is the "logical" thing
to do.  The more complicated the computation rule is, the more important
logical behaviour is.  Consider the following goal (which may occur
inside a perfectly reasonable computation):

	?- N = 1, arg(N, f(a), a), N = 2.

With a left to right computation rule, we get the call arg(1, f(a), a),
which everyone agrees should quietly succeed (then 1 = 2 fails).
With a right to left computation rule (or if the goal was reordered
somehow), we get the call arg(2, f(a), a).
With a parallel computation rule we could get either of the above, or
not call arg/3 at all, or get the call arg(N, f(a), a).

One of the nice things about logic is that the order doesn't matter.
The goal above will run in any order in sequential or parallel NU-Prolog 
and the result will be the same - simple failure.

If you start putting in error messages you lose this (its even worse if
things like arg(N, T, A) fail silently, because the system does not respect
the logic and does not even tell you).

What about finding bugs?  Ideally, there should be a special debugging
mode where various warning messages are given.  Otherwise, the compromise
Richard suggested (allowing, but not enforcing, simple type checks)
seems reasonable.

In NU-Prolog, calls such as ``1 =< a'' results in an error message, then
failure.  I have generally found this useful (it normally indicates an
error), but on one occasion it was a nuisance.  Inside a type checker
which coroutines between bits of user code and type constraints, such
calls are quite acceptable and ideally should quietly fail.  I was forced
to write a separate predicate which explicitly checked the type before
calling the arithmetic test:

        % wait until term is nonvar then check its
        % an integer in the right range
?- check_range(A, _, _) when A.
check_range(A, L, U) :-
        integer(A),
        L =< A,
        A =< U.

Note that I had to force check_range to delay until A was instantiated,
otherwise I could not be sure that the integer check would be called
before =<.  Since this kind of coding is quite rare, =< producing error
messages is an acceptable compromise.

In summary, don't underestimate the nuisance value of error messages
being printed when the system is capable of behaving logically.
Standards should definitely not enforce such messages.  If possible they
should be relegated completely to a debugging mode.

	lee