:- auto_table.

[Jaetan]

Hello,

using the :- auto_table directive inside an object gives the following error on compilation:

Code: Select all

| ?- logtalk_compile( [ toto ] ).
% >>> compiling source file toto...
%     compiling object  toto... 
%         ERROR!    domain_error(directive,auto_table / 0)
%                   in directive (:-auto_table)
++Error[XSB/Runtime] Unhandled Exception: error(error(domain_error(directive,auto_table / 0),directive(auto_table)),logtalk_compile([toto]))
| ?- 

The offending source is here:

Code: Select all

:- object(toto).

    :- auto_table.

    :- public( path/2 ).

    path( X, Z ) :- path( X, Y ), edge( Y, Z ).
    path( X, Y ) :- edge( X, Y ).

    edge( a, b ).
    edge( a, c ).
    edge( b, c ).
    edge( b, d ).
    edge( d, e ).

:- end_object.

Using explicit tabling with :- table( path/2 ) instead is fine, as is putting the :- auto_table directive outside of the object, so this looks like an oversight. This is with Logtalk 2.37.3 and a recent CVS XSB.

[Paulo Moura]

The directive table/1 is supported in the config files of the back-end Prolog compilers that support tabling. The directive auto_table/0 cannot be supported in the same way. Adding support for this directive would imply changes to the Logtalk compiler itself in order to identify all the object predicates that would be tabled.

[Jaetan]

The directive auto_table/0 cannot be supported in the same way. Adding support for this directive would imply changes to the Logtalk compiler itself in order to identify all the object predicates that would be tabled.

Ah, I had not thought of this. So supporting anything that requires some level of dynamic table management (add/del entries, clear table...) would imply that the Logtalk compiler magically figures out what and when to clean. Otherwise, only the simple and static cases (as my example) would be able to use auto_table/0, although there is no real benefit for them, since manually adding table/1 declarations is already easy...

Thank you for your answer!