Re: Tracing with out using trace?

Bruce Horrocks <news@xxxxxxxxxxxxxxxxx> writes:

Not very elegant, I realise, but the print procedure does not know
whether to label the P-->X line on the graph with "son_of" or
"daughter_of" as they could be in either order.

As a way to tell the print procedure what label we want, we can make
the needed information explicit by a term

label([Node1,Node2,Node3,...],Caption)

Users could write the first two clauses of your example (by the way,
"parent_of" implies argument order "parent, followed by child" -- you
can rename to parent_child or child_parent for clarity):


sibling([label([P,X],son_of), label([P,Y],son_of), label([X,Y],sibling)]) :-
son_of(P, X),
son_of(P, Y),
X \== Y.

sibling([label([P,X],daughter_of), label([P,Y],daughter_of), label([X,Y],sibling)]) :-
daughter_of(P, X),
daughter_of(P, Y),
X \== Y.


Yielding:
?- sibling(Ss).

Ss = [label([homer, lisa], daughter_of), label([homer, maggie], daughter_of), label([lisa, maggie], sibling)] ;

Ss = [label([homer, maggie], daughter_of), label([homer, lisa], daughter_of), label([maggie, lisa], sibling)] ;

The backend would be generalised to handle such terms.

avoid putting such restrictions on the user created rules by being
able to duplicate trace and so "know" which link is being followed.

All we have done so far is offering *more features*, i.e., ways of
specifying relations to the backend. Deriving labels from predicate
names is *restricting* the user in names and structure of predicates
(what about auxiliary predicates that *shouldn't* be part of the
graph?), while potentially allowing for more concise rules. In the
version described above, users encode arc labels explicitly and are
free to name their predicates as they want; they also have the full
power of Prolog available to describe any relation they want, and
derived relations are independent from how they are found. You only
need to think about what kinds of terms the drawing routine should be
able to handle, and user-supplied rules should generate (only) these
terms. You can give users access to all features of GraphViz if you
design the interface well. If common patterns arise, you can introduce
special constructs (for example: transitive closures, relation
subsumptions, ...) that a meta-interpreter can handle specially.

Extending a meta-interpreter to keep track of inferences can only help
to make implicit what would otherwise have to be explicit in
user-supplied rules. It *won't* give users more power (in terms of
what kinds of relations they can describe) than they already have by
using plain Prolog as extension language in combination with a
well-defined interface to the backend..


All the best,
-- Markus Triska
.