From ok@atlas.otago.ac.nz  Mon Dec 11 00:15:47 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id AAA09475
	for <prolog@swi.psy.uva.nl>; Mon, 11 Dec 2000 00:15:46 +0100 (MET)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id MAA27137;
	Mon, 11 Dec 2000 12:15:58 +1300 (NZDT)
Date: Mon, 11 Dec 2000 12:15:58 +1300 (NZDT)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200012102315.MAA27137@atlas.otago.ac.nz>
To: irb2@leicester.ac.uk, prolog@swi.psy.uva.nl
Subject: Re:  Compilation of SWI Prolog into Java

Ian R. Bruce <irb2@leicester.ac.uk> wrote:
	I am currently a third year computer science student doing a project on
	creating a web tracer of Prolog programmes. I would appreaciate it if
	you could help me with the following issues:
	
	1) Is there any product avaiable which will allow me to compile Prolog
	Programmes directly into Java or another similar object orientated
	programming language
	
That doesn't sound like a useful thing for your project.
I mean, it ***REALLY*** doesn't sound like a useful thing AT ALL.

A tracer needs a STREAM OF EVENTS from the system being traced.

A debugger needs two synchronised streams:  the same stream of events
from the system as a tracer would get, and a stream of commands going
back the other way.

A simple little Prolog pre-processor (you should be able to plug it in
using term_expansion/2) so that
	p(A1, ..., An) :- Body.
	...
	p(A1, ..., An) :- Body.
turns into

	p(X1, ..., Xn) :-
	    (	trace_call(p(X1,...,Xn)), fail
	    ;   true
	    ;   trace_fail(p(X1,...,Xn)), fail
	    ),
	    '_p'(X1, ..., Xn),
	    (   trace_exit(p(X1,...,Xn)), fail
	    ;   true
	    ;   trace_redo(p(X1,...,Xn)), fail
	    ).

	'_p'(X1, ..., Xn) :- trace_head(p(X1,...,Xn), 1),
			     A1 = X1, ..., An = Xn,
			     trace_neck(p(X1,...,Xn), 1),
			     Body.
	...
	'_p'(A1, ..., An) :- trace_head(p(X1,...,Xn), K),
			     A1 = X1, ..., An = Xn,
			     trace_neck(p(X1,...,Xn), K),
			     Body.

where the trace_{call,fail,exit,redo}/1 and trace_{head,neck}/2 commands
would insert the appropriate events into the tracer's stream are really
all you need for a tracer.  (You might like to catch cuts as well, but
that's rather harder.)

You would also want to remap calls to assert{,a,z}/[1,2], retract/1,
retractall/1, clause/[2,3], and erase/1, so that dynamic code can also
be seen by the tracer.

It's an afternoon's work, tops.


	2)From this Java code how could I produce a graphical representaion of
	the original Prolog programme.
	
With extreme difficulty.  I can't think of anything you might want to know
about the structure of a Prolog program that wouldn't be *FAR* easier to
discover from the original Prolog text than from any Java transmogrification
of it.

I get a strong impression that Ian Bruce is confident with Java but knows
very little about Prolog.  That's fine, to know very little about Prolog is
to know vastly more than the bulk of humanity, who have never heard about it.

The thing is, I don't believe you can write a useful Prolog tracer of any
kind, or a useful Prolog program structure displayer (which are two extremely
different things) without having done enough Prolog programming to have a
feel for what *kinds* of trace are useful (answer: ones that can be controlled
quite tightly from within the Prolog program itself to show you as little as
possible, just the tiny fraction that is interesting for the current
experiment) or what *kinds* of program structure display are useful (in my
experience with Lisp and C program structure displayers, *none* unless they
get the structure *right*, and I am unaware of any structure display for C
that does get the structure right).  The one structure display that
was useful in Lisp was the graph showing which functions *actually* called
which functions, not the graph showing which functions *might* call which
functions.  Even that required a great deal of zooming and scrolling.

It is important to remember that graphic communication is low bandwidth
communication.  A picture is not worth a thousand words unless it can
convey a thousand words' worth of information, and you really can't fit
that much detail into the average CASE diagram and still read it.  Then
there are the programmers (who may actually be a majority) who find
pictures much harder to work with than text.  The absolutely central thing
in all graphic communication is choosing what to leave out so that people
can see the relevant information without distraction.

For the graphic program display, don't forget that Prolog is a *DYNAMIC*
language.  Any approach that tries to translate a Prolog "program" to some
other form once and for all is doomed, because there is really no such
animal as a Prolog "program".  (Mercury is different.)  The graphic
representation, and the display, *MUST* be able to cope with

	call(X)		what's X? you don't know yet
	assert(C)	and its relatives
	clause(H, B)
	
If it doesn't, it won't be only 90% complete, it will be 100% useless.
The UNIX system I normally use has a fancy software engineering environment,
and I simply cannot afford to use it, not because of the price, but because
its failure to track function pointers means that its opinion of the structure
of a C program is so seriously incorrect as to be dangerous.

