Mcintyre.pl, which is part of the PITA package, has apparently only partly been ported to XSB.
While it passes the test suite, other exported predicates still rely on erase/1 and asserta/2, two SWI-Prolog built-ins related to SWI-Prolog's clause-indexing system.
These obviously raise an "unknown predicate" error when attempting to use them under XSB.
I replaced this in my version, which I have attached here, with ordinary asserts and retracts; I've also renamed tab/2, which is a system predicate in XSB, and as Theresa suggested in London, I trie-indexed three of the dynamic predicates for which only facts are ever asserted and order is irrelevant.
Thanks, Felix. I need to start updating PITA on XSB and this is a way to start.
Both XSB and SWI support conditional compilation so we'll use your version as a basiss and add statements like:
:- if(current_prolog_flag(dialect,swi)).
tab(A/B,A/B1):- B1 is B + 2.
:- elseif(current_prolog_flag(dialect,xsb)).
erase(Term):- retract(Term).
:- endif.
Using statements like these, we'd have one mcintyre.pl that works for both XSB and SWI. I want to get Fabrizio in the loop to make sure he knows what we're doing, and to help update the SWI side as well as the XSB side.
SWI's use of assert/2 together with erase/1 makes retraction very fast, since assert/2 returns a reference to the clause asserted. This is something we should consider for XSB. However, our interned tries do in fact support a trie_intern/5 which returns a similar reference for interned tries (cf. Volume 1, Section 7.4.1 of the XSB manial.) which should make things very fast if you use it.
So thanks for the report and code and let me know if I can provide further help.
Theresa
Thank you! In this case, at the only place where we actually use the asserta/2 and erase/1 combination, we are actually asserting two (impure) proxy clauses for a goal, where order does matter.
I don't think this is a bottleneck though, so it shouldn't have any serious performance impact there.
More work with Mcintyre unearthed the following additional issue:
The predicates save_..., which are supposed to copy "sampled" facts into a new predicate "mem" and then retract the "sampled" facts, are currently implemented using the schema
In SWI-Prolog, the failure-driven loop executes correctly, but XSB doesn't seem to take well to backtracking over a partially retracted predicate (it hangs as soon as sampled/3 has more than one solution).
One portable fix would be doing it in two passes, as