Tabled DCG

[Jaetan]

I am trying to use a tabled DCG from within a Logtalk object. To this end, I would like to be able to call tphrase/1 without having to do the same kind of analysis as Logtalk does in phrase/2. Specifically, I'd like to be able to write:

Code: Select all

:- object( parse ).

    :- public( parse/2 ).

    parse( N, T ) :-
        tphrase( znumber( N, T ) ). 

I cannot get Logtalk to translate znumber to the actual name of the predicate, even if asking politely with a big hammer in the hand I believe parse/2 should read:

Code: Select all

    parse( N, T ) :-
        self( S ),
        tphrase(parse_0_znumber_4( S, N, T )). 

I understand tphrase/1 is non-standard, so supporting it is not high on the todo list (especially if other tabling Prologs do things differently). I would just like to know if such an approach is possible, or if I should keep XSB specific parser code in a module, e.g. outside Logtalk, and just plonk a protocol in front of it (the implementation of the protocol would then rely on :- use_module and keep the interface at the level of logical variables).

Thanks in advance for your advice.

[Paulo Moura]

As you wrote, tphrase/1 (and the related predicates) are specific to XSB. Keeping XSB specific parser code in a module, as you suggest, is probably the best solution. From a quick reading of the XSB documentation, it's not clear if the supporting word/3 dynamic predicate is global or module-specific. Using this tabling mode within Logtalk objects would require word/3 to be local to the object. Nevertheless, I don't expect that the integration of these XSB tabling predicates with Logtalk to be currently feasible.

[Jaetan]

Thank you for your advice. I will stop my "do it all in Logtalk" approach and hide code that is specific to a Prolog back-end behind a Logtalk interface.

As for XSB's word/3 dynamic predicate, calling tphrase_set_string/1 shows it asserts clauses in XSB's dcg module, without possibility of choice. So it is interesting only if the parser has the quadratic behaviour tphrase/1 wants to avoid, and more time is spent parsing than asserting the words to be parsed. So whether it is good or not really depends on the problem to solve...

Anyway, thanks again!