🚀 go-pugleaf

In reply to an article of Richard O'Keefe, and more especially to the 
following two fragments :

> 	BIM Prolog has a debugger with lots of stuff in it.  (I find it
> 	bewilderingly complex, but that's just my personal opinion.)

> If anyone who described a debugger at the Prolog Environments workshop at
> SLP 88 is reading this newsgroup, how about posting a short description
> here?  (And of course, anyone working on Prolog debugging who _didn't_
> describe the work at SLP 88, please post too.)

As you say it yourself : finding the BIM_Prolog debugger bewilderingly 
complex, is your personal opinion.  How could you have another opinion 
on BIM_Prolog ?
Anyway, I know a lot of people don't share that opinion.  Not only 
researchers at our department, but also students (who aren't Prolog nor
debugger guru's), use that debugger without noticeable difficulties. 
You don't have to understand ALL commands to be able to debug a program.
It's possible to start with only a basic set of commands (that are in 
BIM_Prolog just the same as in any other Prolog).  As one becomes more 
experienced or more demanding, he can add other commands to his knowledge. 

Nevertheless, I agree that the BIM_Prolog debugger might look complex, 
at first sight.  This is because BIM_Prolog supports three methods for 
debugging, and wandering at all commands together, surely makes it look 
complex.  You should have in mind that the commands are meant to be used 
in one specific method ('divide et impera' as a roman consul once said). 

As you asked, I will try to give an overview of the BIM_Prolog debugger. 
I hope this will make it somewhat clearer.

There are mainly three different debugging approaches supported in 
BIM_Prolog : 
   1. The most commonly used box-model based step-wise program execution. 
   2. An algorithmic-like post-execution trace analyser.
   3. Source oriented, break point based program execution.  
On SUN workstations, there is a multi-window interface, with control panels 
and command buttons and the like, which makes it possible to debug your 
program with the mouse. 
The three methods can be mixed : one can keep a trace of the program during 
step-wise execution and analyse it afterwards.  Break points can be set 
together with spy points.  By choosing the right resume command, one can 
switch between port and source oriented debugging.
Although this mixed usage of debugging methods is perfectly possible, it 
is not recommended and not necessary.  Each method is strong enough to 
stand alone. 

1. Stepping debugger
--------------------
In BIM_Prolog, the box has five ports : the usual four (CALL, EXIT, REDO, 
FAIL) and an additional UNIFY port, that is reached immediately after 
successful unification. 
Global port control includes possibilities to determine which ports have 
to be displayed and on which ports the execution must be suspended (known 
as 'leashing').
There are commands for resuming execution in different ways, as well forward
as backward. 
Output control commands let you specify how the debugger must write out 
its information, independent from the program output. 
A very useful feature (especially in source oriented debugging) is a command 
for printing the current value of a variable.  

2. Post-execution trace analyser
--------------------------------
In this approach, a trace is recorded of the execution of a query.  After 
completion, the trace can be analysed interactively, in a breadth first 
way.  The analyser gives it output in source form.  Here is an example of 
such output :

  0: qsort( [3,4,1,2,5],_10 ) :-
  1:    split( 3,[4,1,2,5],_18,_19 ),
  2:    qsort( [1,2],_49 ),
  3:    qsort( [4,5],_87 ),
  4:    append( [1,2],[3,4,5],_10 ).
Command : 

It shows a qsort/2 goal, solved in 4 subgoals.  The arguments are printed 
as they were instantiated at the CALL port.  This means you see how each 
subgoal was called.  On simple demand, one can get the arguments as 
instantiated at the EXIT port.  In this case, you see how the subgoal has 
been executed. 
If a goal has failed, it's displayed with all of its succeeded subgoals 
and with the failed subgoal, marked as such. 
The analysis can go on by selecting a subgoal for further investigation or 
by going back to the ancestor goal.  There are also commands for going to 
the next solution of a goal.
On a workstation, this can be combined with a separate source window in 
which the corresponding piece of the source program is indicated by the 
analyser. 

3. Source oriented debugging
----------------------------
With this technique, the user sets break points at certain lines of his 
program.  The most elegant way to do this, is with the window interface. 
You indicate the line in the source window and click the 'stop at' button. 
As feedback, stop signs are drawn near each line that contains a break 
point. 
When a break point is reached during execution, the program is suspended 
and the corresponding source line is indicated (with an arrow in the source 
window).  Execution can be resumed by stepping, going to the next line or 
continuing up to the next break point.  The stepping resume, will suspend 
the execution as soon as another source line is reached.  Going to the next 
line means that all goals on the current line are executed silently. 
There are a number of commands for looking through the sources of your 
program.  One can ask to display the ancestor goal in the source window, 
or the definition of a predicate. 
Other commands are provided for managing the break points. 
As mentioned above, one can print the value of a variable.  The variable 
is pointed at in the source window and then the print command button must 
be clicked. 
One of the advantages of break points over spy points, is that you have 
more selectivity.  Instead of stopping on each call of a predicate, it is 
possible to stop only on the call of that predicate from one specific goal. 
It's also easy to limit the suspensions to clauses of a predicate that 
are successfully unified, instead of having to skip from redo to redo. 

Another useful feature, available in all three debugging methods, is an 
alias mechanism.  This can be used for redefining or abbreviating the names 
of commands or for abbreviating commonly used (complex) command constructions. 

For more information on the BIM_Prolog debugger, please contact :

	B.I.M.			Tel.: +32 2 759 59 25
	Kwikstraat 4		Tlx.: 63518 bimsa b
	B-3078 EVERBERG		Fax.: +32 2 759 47 95
	BELGIUM			e-mail : dani@sunbim 
					 ...mcvax!prlb2!sunbim!dani

Alain Callebaut
K.U.Leuven - Dept. of Computer Science