I’d like to use prolog_trace_interception/4 to construct a custom tracing facility within a module. The documentation suggests this was a dynamic predicate so I was expecting it to work much like the exception/3 hook (multifile, dynamic). When defined, it appears to be static (using predicate_property) although it works as intended. However, this prevents another module from doing the same (redefined static procedure warning).
Bug or misunderstanding?
It is actually initially not defined at all. That could be a good idea, so you can define it as static if you don’t want anyone to mess with your definition or dynamic if you do not mind. Different definitions typically cooperate poorly.
Note that if you want basically a normal trace but you to hide some details and present things a little different, there are other ways to achieve that.
I thought I was trying to define it dynamic, multifile, but was doing it wrong. Now works fine, just need to declare it as such in each module.
What I’m trying to do is trace instructions in a VM implemented in Prolog (like local propagation in clpBNR) without incurring overhead when not tracing. So effectively I’m trying to trace a single (local) predicate within the VM implementation. And I’d like to do so while minimally impacting normal debug functionality or other VM’s that might be running at the same time. So the instances of prolog_trace_interception just need to fail if the “instruction” isn’t one of interest, analogous to using exception for initializing global vars. prolog_trace_interception/4 actually seems to work pretty well for this, now that I’ve declared it properly.
Not fail, return continue.
Action must be unified with a term that specifies how execution must continue. The following actions are defined: …
To explain in more deatil.
You don’t want prolog_trace_interception/4 to fail as it is a hook that runs inline with the code. So if it fails the goal that initiated it will fail. You want to set the Action value to continue if you want the code to continue as normal after doing whatever is desired within prolog_trace_interception/4.
Not really. Failing does the default thing the internal debugger does (display ports, ask for action, etc.). Succeeding with continue means you have taken care of the (user) interaction and the system should continue without invoking the default debugger. The tracer never alters the logic of the program unless your return one of the actions that does (i.e., retry).
Yes, this. Action=continue corresponds to the success case when the predicate is one of interest, i.e. print trace message and continue. Otherwise fail to default debugger semantics (or some other clause of prolog_trace_interception).