home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / prolog / 1603 < prev    next >
Encoding:
Text File  |  1992-08-26  |  3.5 KB  |  103 lines
  1. Newsgroups: comp.lang.prolog
  2. Path: sparky!uunet!mcsun!sunic!sics.se!lhe
  3. From: lhe@sics.se (Lars-Henrik Eriksson)
  4. Subject: Re: SICStus prolog problem
  5. In-Reply-To: cjhs@minster.york.ac.uk
  6. Message-ID: <1992Aug26.145353.21444@sics.se>
  7. Sender: lhe@sics.se (Lars-Henrik Eriksson)
  8. Reply-To: lhe@sics.se (Lars-Henrik Eriksson)
  9. Organization: SICS, Kista (Stockholm), Sweden
  10. References: <714691472.12060@minster.york.ac.uk> <714823911.21006@minster.york.ac.uk>
  11. Date: Wed, 26 Aug 1992 14:53:53 GMT
  12. Lines: 89
  13.  
  14. In article <714823911.21006@minster.york.ac.uk> cjhs@minster.york.ac.uk writes:
  15. >: I have a program in SICStus prolog that makes extensive use of the wait
  16. >: declaration. Program (137 lines) supplied to anyone who is curious.
  17. >: 
  18. >: The problem is that it runs ok interpreted, but fails when compiled.
  19. >: Insertion of a diagnostic in a critical place makes the compiled
  20. >: version behave like the interpreted version.
  21.  
  22. I suspect that the problem you have run into is the same one that I
  23. once encountered and that caused me much grief before I got an
  24. explanation and a workaround.
  25.  
  26. If you have a clause body that looks like this:
  27.  
  28.     .... baz(...), !, ....
  29.  
  30. and the call to baz causes blocked goals to run, the compiler executes
  31. the cut *before* running the blocked goals. This may cause the program
  32. to fail even if it works correctly under the interpreter.
  33.  
  34. The following program illustrates the point:
  35.  
  36.     :- block bar(-). /* :- wait bar/1 before SICStus 2.0 /*
  37.     foo :- bar(X), baz(X), !.
  38.     bar(2).
  39.     baz(X) :- X=1.
  40.     baz(X) :- X=2.
  41.  
  42. The reason baz/1 is written in a slightly odd way is to prevent
  43. indexing. It is essential that a choicepoint is created.
  44.  
  45. Calling foo/0 as a goal succeeds under the interpreter, but fails
  46. under the compiler.
  47.  
  48. The compiled code calls baz(X), which succeeds, binding X to 1. The
  49. call to bar/1 is now unblocked, but *not* run.  First Sicstus cuts
  50. away the choice point in baz/1, *then* calls the unblocked goal. Of
  51. course bar(1) will fail, and since the choicepoint in baz/1 has been
  52. cut away, the call to foo/0 will also fail.
  53.  
  54. The interpreter will do the cut only *after* calling bar/1, so in that
  55. case foo/0 will succeed.
  56.  
  57. Running the program gives the following result:
  58.  
  59.     SICStus 2.1 #5: Fri Apr 24 17:00:24 MET DST 1992
  60.     | ?- [foo].
  61.     {consulting /home1/lhe/foo.pl...}
  62.     {/home1/lhe/foo.pl consulted, 20 msec 1104 bytes}
  63.  
  64.     yes
  65.     | ?- foo.
  66.  
  67.     yes
  68.     | ?- compile(foo).
  69.     {compiling /home1/lhe/foo.pl...}
  70.     {/home1/lhe/foo.pl compiled, 100 msec 512 bytes}
  71.  
  72.     yes
  73.     | ?- foo.
  74.  
  75.     no
  76.  
  77. The solution is to insert a dummy goal (likely the diagnostic in your
  78. case!) before the cut, e.g.
  79.  
  80.     foo :- bar(X), baz(X), true, !.
  81.  
  82. Now the compiled code runs as expected.
  83.  
  84. >: SICStus 0.6 #17: Mon Apr 9 09:37:54 BST 1990
  85. >: Copyright (C) 1987, Swedish Institute of Computer Science.
  86. >: All rights reserved.
  87. >: 
  88. >: Am I out of date? Who can I contact to fix the problem?
  89.  
  90. As you can see, I run the latest version of Sicstus, and the problem
  91. is still there. According to Mats Carlsson, the Sicstus implementor,
  92. there is no good way of changing the implementation to avoid the
  93. problem.
  94.  
  95. The manual should really state clearly that this can happen. Not
  96. everyone is as fortunate as I to work in the same place as the
  97. Sicstus implementor.
  98. -- 
  99. Lars-Henrik Eriksson                            Internet: lhe@sics.se
  100. Swedish Institute of Computer Science           Phone (intn'l): +46 8 752 15 09
  101. Box 1263                                        Telefon (nat'l): 08 - 752 15 09
  102. S-164 28  KISTA, SWEDEN                         Fax: +46 8 751 72 30
  103.