Strange interaction between SWI Dicts and Logtalk

[kaiser185]

Dear Mr. Moura and all discussion board members,

Playing around with the interaction between SWI prolog’s dicts and Logtalk, it would seem that the Logtalk compiler’s linter makes a mistake when analysing goals that make use of the ‘dot’ access mechanism for dict fields, BUT only when unification is done with compound terms and not when simply unified with a variable.

Here is a minimal example of what I mean:

:- object(dict_test(_DICT_)).

    :- public([error/1, error/2, no_error/1, no_error/2]).

    error(Value) :-
        foo(Value) = _DICT_.key.

    error(Dict, Value) :-
        foo(Value) = Dict.key.

    no_error(Value) :-
        Value = _DICT_.key.
    
    no_error(Dict, Value) :-
        Value = Dict.key.

:- end_object.

Which generates the following linter warnings (though compilation succeeds):
*     Goal is always false: foo(B)=C.key
*       while compiling object dict_test(A)
*       in file /Users/_/workspace/learning/prolog/logtalk/dict_linter_error/test.lgt between lines 5-6
*     
*     Goal is always false: foo(B)=C.key
*       while compiling object dict_test(A)
*       in file /Users/_/workspace/learning/prolog/logtalk/dict_linter_error/test.lgt between lines 8-9

And here are the corresponding queries that exemplify that it works as one would expect:

?- Dict = _{key:foo(bar)}, dict_test(Dict)::(error(Value), error(Dict, Value)).
Dict = _40660{key:foo(bar)},
Value = bar.

?- Dict = _{key:foo(bar)}, dict_test(Dict)::(no_error(Value), no_error(Dict, Value)).
Dict = _43096{key:foo(bar)},
Value = foo(bar).

?- Dict = _{key:foo(bar)}, dict_test(Dict)::(no_error(foo(Value)), no_error(Dict, foo(Value))).
Dict = _47134{key:foo(bar)},
Value = bar.

This leads me to pose the following set of questions:
(a) Is this something that could lead to unexpected failures of the code, or have unexpected side-effects?
(b) Is this due some strange interaction between the term expansion mechanism used for SWI’s Dict specific operators and goals with the Logtalk compiler?
(c) More importantly, what do you think of the use of SWI Dicts as the parameters of parametric objects? It would seem that one could have a powerful mechanism for (i) encapsulating a variable and not necessarily pre-specified number of parameters (leading to easier code evolution) and (ii) for removing the reliance on argument position in the object term allowing one to have a more expressive access mechanism as exemplified in the code?

I look forward to hearing your thoughts.

Kind Regards,

-K

P.S. Looking at Logtalk’s documentation, it would seem that the mode declared for the catch/3 built-in is incorrect (i.e. catch(?callable, ?term, ?term)) since, if I’m not mistaken, the third parameter should be a callable term as well, and not merely a term.

[pmoura]

Logtalk linter checks occur when reading a source file and thus before the generated Prolog code is handed over the used Prolog backend. In this particular case, SWI-Prolog expansion of the dot notation occurs only when compiling the generated intermediate Prolog files and thus after the linter was run. As goals such as foo(Value) = _DICT_.key are trying to unify compound terms with different functors, the linter reports them as goals that are always false. Note the Logtalk provides an always_true_or_false_goals linter flag that defaults to warning but can be set to silent locally in the source file using the set_logtalk_flag/2 directive:

:- set_logtalk_flag(always_true_or_false_goals, silent)

or using the corresponding compiler option in a loader goal, something like:

logtalk_load(my_dicts_code, [always_true_or_false_goals(silent)])

Still, using SWI-Prolog dicts dot notation is not advised from Logtalk source code. See the pardicts example notes for details.

Some of the advantages you mention for using dicts can be accomplished in a portable way. Logtalk parameter variables remove the dependency on argument position in the object (or category) identifier. Logtalk portable dictionaries and nested_ dictionaries libraries can often be used in alternative to the proprietary SWI-Prolog dicts feature. For example, instead of Dict = _{key:foo(bar)} you would use something like avltree::as_dictionary([key-foo(bar)], Dict). You loose the syntax simplicity of the dot notation and dict creation but that's not something that can be done portably. But note that you can always define predicate aliases for a lighter syntax in a local context.

P.S. Thanks for the documentation bug report. Fixed and credited in the current git version.