Some time ago I stumbled upon Shapiro’s work on metainterpreters for debugging
(they were mentioned in the Art of Prolog) and, having fallen in love with the
concept, started skimming his thesis and whichever article I could find related
to “prolog meta interpreter debugging”).
The problem now is that, while the approach seems really brilliant to me, I
don’t see a suite of tools in SWI prolog that follows those principles.
What am I missing? Here are some theories:
I’m not finding the tools, but they exist somewhere (?)
Everyone is using this, but since the meta-interpreters are so easy to
define, everyone has his slighlty differing hand-crafted version.
Those tools were a nice proof of concept but the application of similar tools
outside toy examples is not worth it (maybe because they have problems with the
impure parts of prolog, or negation).
So which of these is true? I guess I’d like to exclude the explanation “prolog
has a small community” because the tools are so easy to express that the
question would become: “What are you using instead?”
I’d also like a guide in the recent literature for this problem. What are the
most promising approaches in the space? What should I be reading? Most papers
I’m finding on the argument stopped in the early 90’
tl;dr meta-interpreters for debugging. Why are we not using them as a community?
@EricGT not at all: I often find traces too verbose and too low level, and the user still has to analyze that manually. Some improvements are possible on that, I saw @DouglasRMiles doing that in some packages, and I myself tried with https://github.com/meditans/gestalt
There is some more literature on the topic by searching the keywords I suggested earlier, but the gist of it is defining a meta-interpreter that, for example, can evaluate your code to a certain depth and identify what’s looping in case of non-termination, or use the user as an oracle to debug why a solution is not showing up.
I vaguely remember trying Shapiro’s code a long time ago. The papers looked good – but the code was clearly “research quality” and would have needed a lot of work to become useable. I suspect that a combination of trace/2 and wrap_predicate/4 would work better for large programs.