Getting Source Info During Trace

Help!
1

My apologies in advance, I’m unfamiliar with this area. I have been ruminating on what I would like a really powerful educational debugger for Prolog to look like, and to do what I’m imagining it would need to be aware of the source, aware of the trace, and aware of how they are linked.

I’m not sure how to achieve that last part. I understand that the trace will show a “call” for a clause that unifies for the parent goal, but how can one tell from the trace output what file or line number that clause was found on? I don’t remember ever seeing that info in a trace output.

My idea is essentially a visualized tree of trees. If you have ever played go or chess online you may be familiar with a variation tree, where you can rewind a game, make a different move, and a new branch is created in the game history tree at the bottom of the interface.

I’m imagining an interface like that, where nodes in the bottom tree represent calls, and branching represents a redo. Instead of each node displaying a board position, it displays a tree representing the justification tree that would be generated by the current position in the trace, illustrating what had been unified with what so far. Successful search routes would be highlighted green in the outer tree. Each green leaf node would be an answer, and would display the trace for just that answer. Green branches would represent the points at which two partially similar answers diverged.

What I would like is for the justification tree for a given node to show the source code that the call came from, to understand what subgoals are being added at that point, and why. Potentially with any immediately preceding comments, or other meta-data about the clause, like the file name, etc.

I feel like this would make trace output a lot easier to process, because the navigation tree represents the search path that was followed, but each node displays the cumulative effects of that and all previous successful nodes. So you are seeing the incremental and the cumulative effect at the same time. And you could watch it generate, which would illustrate how resolution happens, and you could also rewind it, to understand specific steps.

So two questions: does that seem like something worth trying, and where would I find the meta-data for the clause being used in a given call?

2

Hello Jason,

Sounds interesting, I wonder exactly what you mean by “powerful” and “educational” in this context. What is the target audience that you have in mind? IMO, the meaning of “power” can vary greatly based on the level of expertise. For a long time hacker, a “powerful” interface might be one that let’s them do exactly what they want to do with as little friction as possible. OTOH a newbie may consider an interface very powerful for providing great guidance for common tasks and hiding as much complexity as possible.

Either way, did you get a chance to play around with the built-in SWI-Prolog graphical debugger? I definitely consider it powerful. I’m not sure it’s educational, I’d say illuminating for sure.

The regular trace currently doesn’t show source locations. To get them you need to “intercept the tracer” with prolog_trace_interception/4. Within that hook, you can obtain and print the relevant source information, or you can store it somewhere and display it afterwards in another way. That’s how the built-in graphical debugger works. (It’s also how my Debug Adapter Protocol server works, which is a debugger backend that provides a standard interface).

1 Like
3

See:

Be sure to click on the following icons in the upper right and read through them, the sytax used is slightly different.

image

1 Like
4

Thanks. I’m aware of the debugger, but I am looking for something that will fit inside my web based visual IDE. My focus is firmly on beginners doing legal knowledge representation, and illustrating the resolution process in a manner similar to the Prolog visualizer, but where the passage of time can be reversed, and where legal source text can be part of the context for why the program took a given step.

I’ll take a look at both of those, thanks.

5

The visualizer is close to what I want, but my users never need to see the actual Prolog code, and I do need them to understand the context of where the options considered arise.

I’m also not sure of the utility of displaying things like “p(X) doesn’t unify with q(7)”, because in fact the reasoner never considers unifying unless the functor and arity are the same, and there would be no mystery as to why.

I need to do a lot of work to prototype what I’m imagining, and there are parts of it that I’m totally unclear about, like how to allow access to a natural language version of the clauses, without crowding the interface horribly.

But the animated aspect of the Prolog Visualizer, and the way it builds the tree, is similar to what I would want.