🚀 go-pugleaf

In article <1992Aug26.145353.21444@sics.se> lhe@sics.se (Lars-Henrik Eriksson) writes:

   In article <714823911.21006@minster.york.ac.uk> cjhs@minster.york.ac.uk writes:
   >: I have a program in SICStus prolog that makes extensive use of the wait
   >: declaration. Program (137 lines) supplied to anyone who is curious.
   >: 
   >: The problem is that it runs ok interpreted, but fails when compiled.
   >: Insertion of a diagnostic in a critical place makes the compiled
   >: version behave like the interpreted version.

   I suspect that the problem you have run into is the same one that I
   once encountered and that caused me much grief before I got an
   explanation and a workaround.

   If you have a clause body that looks like this:

	   .... baz(...), !, ....

   and the call to baz causes blocked goals to run, the compiler executes
   the cut *before* running the blocked goals. This may cause the program
   to fail even if it works correctly under the interpreter.

   The following program illustrates the point:

	   :- block bar(-). /* :- wait bar/1 before SICStus 2.0 /*
	   foo :- bar(X), baz(X), !.
	   bar(2).
	   baz(X) :- X=1.
	   baz(X) :- X=2.

   The reason baz/1 is written in a slightly odd way is to prevent
   indexing. It is essential that a choicepoint is created.

You _will_ get indexing with this formulation too, but that
doesn't change anything for your example.  There will be a choicepoint
since X is unbound.

   Calling foo/0 as a goal succeeds under the interpreter, but fails
   under the compiler.

   The compiled code calls baz(X), which succeeds, binding X to 1. The
   call to bar/1 is now unblocked, but *not* run.  First Sicstus cuts
   away the choice point in baz/1, *then* calls the unblocked goal. Of
   course bar(1) will fail, and since the choicepoint in baz/1 has been
   cut away, the call to foo/0 will also fail.

   The interpreter will do the cut only *after* calling bar/1, so in that
   case foo/0 will succeed.

   [...]

   The solution is to insert a dummy goal (likely the diagnostic in your
   case!) before the cut, e.g.

	   foo :- bar(X), baz(X), true, !.

   Now the compiled code runs as expected.
   The manual should really state clearly that this can happen. 
   [...]

But it does, witness page 110 in the User's Manual for version 2.1.

The check for unblocked goals is done at procedure calls.  To fix the
interpreter/compiler discrepancy, nearly all built-in predicates that
compile in-line would have to check.  Also, the compiled code would
have to include information to make it possible to safely "escape"
from the current execution and invoke the unblocked goals.
We haven't yet figured out a way to do this without undue overhead.
--
Mats Carlsson
SICS, PO Box 1263, S-164 28  KISTA, Sweden    Internet: matsc@sics.se
Tel: +46 8 7521543     Ttx: 812 6154 7010 SICS     Fax: +46 8 7517230