Looking for advice about how to trace prolog execution and reuse that trace

[zmaril]

Hello!

I'm new to scryer and prolog and I have a question about how to get and use a trace of a program's execution. I'd like to see the steps that were made by the program and ideally work with them as data again. I've been trying to write a puzzle solver, explainer and grader for a bit now and while I can write a solver in prolog, writing an explainer/grader has been more challenging. If I could get the trace of the solver program's execution and work with that, then I might be able to turn that execution trace into an explanation of steps taken and have an explainer/grader. I've tried to use debug's $/1 command but it hasn't given me much of what I wanted.

Is there a way to get the trace of a program's execution and then work with it again in scryer-prolog?

Thank you for the great software!

[pmoura]

Maybe using the Logtalk debugger tool? It allows you to get a full trace of your goals, assuming that you can encapsulate your code inside an object. The tool also includes a dump_trace utility object for dumping a full trace to a file. The debugging messages uses Logtalk's message printing mechanism so they can be intercepted in order to convert them to the explanation steps you want to generate. Is your code publicly available?

[pmoura]

An example using the potions puzzle:

$ scryerlgt
...
?- {debugger(loader)}.
...
?- {debugger(dump_trace)}.
...
?- logtalk_load(puzzles(potions), [debug(on)]).
...
?- dump_trace::(start_redirect_to_file('potions_trace.txt', potions::potions(P1,P2,P3,P4,P5,P6,P7)), stop_redirect_to_file).
...

As the dump_trace object already uses the message printing mechanism to redirect the trace to a file, the easiest solution would be to copy and modify it so that the trace output would be exactly what you want. The tracing messages are:

• tracing_port(Code, Port, N, Goal, MaxDepth)
• tracing_port(Code, Port, N, Goal)

Likely you would need only to care about the Port (possible values are {fact, rule, call, exit, redo, fail, exception}) and Goal arguments.

[zmaril]

That's super helpful thank you! No public code yet, nothing I would want to show the world, but maybe soon if this works out. I'll let you know if I get this working.

[EricGT]

@zmaril

I've tried to use debug's $/1 command but it hasn't given me much of what I wanted.

Take most of what follows as food for thought. I note it for you and others that might be working on teaching Prolog via tracing demonstrations and some of the pitfalls I am learning in creating such related things.

What I am working on is with SWI-Prolog. One of the main ways to get debug information is via prolog_trace_interception/4. Since it hooks into a level lower than the Prolog code the ability to look at more than just the Prolog code is available, e.g. VM instructions.

While prolog_trace_interception/4 is useful as the root of data that leads to other means of examining the program, I don't know how much it will help when I try to do other models based on things such as global variables, attributed variables, coroutining, SLG resolution, s(CASP), etc.

Also over the years I have come to understand those coming from procedural languages to functional and logic languages for the first time typically don't understand bound variables. Many of the Prolog trace representations don't make this apparent, they may show it but don't explain it, thus hiding a critical concept.

Concepts needed to understand everyday Prolog but that are at times not clearly explained in trace output are:

1. Bound variables
2. Choice stack (the call stack is taken to be be present and understood so not in this list)
3. Cut
4. Backtracking on fail and/or cut
5. Clause indexing
6. Meta calls
7. Optimizations (SWI-Prolog can optimize away some goals. These missing goals will not be noted in trace output with optimization turned on which is the default).

Another lesson learned about tracing based on hooks is that of synchronizing the hook events. If only one hook is used the problem is not present but if multiple hooks are needed and they do not have a synchronizing value such as a timestamp, then it is either hard or impossible to synchronize the events and thus multiple hooks can not be used. For my problem this might become a reality in which case I am considering adding a new set of hooks into SWI-Prolog.

Then there is the Byrd box. While this is great for understanding a simple goal, when you start adding predicates calling predicates and try to show all of the Byrd boxes in one image, well just try it. I am curious if this can be done and even be comprehendible.

[UWN]

Since you are new to Prolog, avoid traces as much as you can. Think of how to learn to drive a car. Nobody starts by the pistons and valves in the engine and how they rotate. There are many good reasons to be reluctant to such an approach. Tracers show you every little detail that Prolog has to execute. Much too much than you can understand.

Instead, focus on what Prolog programs define, that is which set of solutions they are describing. Certainly, this will only work if you are using the pure subset of Prolog. Also, consider how changes to your program affect the set of solutions a predicate describes.

In case of unexpected failures, generalize a program to localize the error as in these examples. And in case of unexpected solutions, a specialization may help.

Even in the case of highly procedural issues like non-termination it is far more better to stick to less than the complete infinite execution trace. There, a failure-slice helps to understand the issues much better.

Much later on, you will need proof trees that are typically generated with meta-interpreters. These are already somewhat closer to traces but they still leave out lots of irrelevant detail.