list filtering

[mvolkmann]

I wrote a list_matching rule that relates the list L0 to the list L which contains all elements for which predicate P holds.
Is there a better way to implement this? I feel like the associated check rule is more complicated than it should be.

:- use_module(library(reif)).

check(P, E, B) :-
  Goal =.. [P, E],
  ( Goal -> B = true; B = false).

list_matching(L0, P, L) :- tfilter(check(P), L0, L).

% For this example I want to find strings that are longer than five characters.
is_long(S) :- length(S, Len), Len > 5.

demo :-
  L0 = ["apple", "banana", "cherry", "date"],
  list_matching(L0, is_long, L),
  write(L), nl. % ["banana", "cherry"]

[pmoura]

That functionality is provided by some libraries. E.g.
https://logtalk.org/library/metap_0.html#include-3

[mvolkmann]

I'm not clear on the relationship between Logtalk and Scryer Prolog.
I downloaded the file metap.lgt, but I can't just pull that into a Prolog file with :- use_module('metap.lgt').
Is there a way for me to use the include predicate it defines in Scryer Prolog?

And as a separate question, are there improvements that could be made to the code I shared above?

[pmoura]

Logtalk uses Prolog as a backend compiler (see https://logtalk.org for details). Thus, to load a Logtalk library, you need to start Logtalk with your choice of the backend, Scryer Prolog in this case:

$ scryerlgt
...
?- {meta(loader)}.
...
% (0 warnings)
   true
;  ... .
?- use_module(library(lists)).
   true.
?- [user].
is_long(S) :- length(S, Len), Len > 5.

?- meta::include(is_long, ["apple", "banana", "cherry", "date"], Included).
   Included = ["banana","cherry"].

But I give you that link (to the meta::include/3 library predicate) just as a code example.

[UWN]

include/3 be it in Logtalk or anywhere else does not provide "that functionality", because it violates monotonicity, if the fliter predicate does not guard against insufficient instantiations.

[pmoura]

Logtalk include/3 library predicate is compliant with its specification, include(+callable,+list,-list), which requires a callable first argument (same as in @mvolkmann definition for the check/3 predicate).

Should library predicates in general guard against arguments outside their specification? Should the burden be instead on the caller? Should the system provides the programmer the means to optionally guard against misuse? These are all interesting questions that have long been debated. But claiming that a useful property is violated when using a predicate outside its specification is questionable in itself.

[triska]

It seems everything to say about this code has already been stated elsewhere and also quite recently, so I post here only a query showing a mistake in the program:

?- check(is_long, A, B).
   A = [_A,_B,_C,_D,_E,_F], B = true, unexpected, incomplete

This is a mistake in the program, since adding a constraint elicits an answer not shown above:

?- A = [_,_,_,_,_,_,_], check(is_long, A, B).
   A = [_A,_B,_C,_D,_E,_F,_G], B = true.

The program thus violates a fundamental property we expect from logic programs: Adding a constraint does not yield new solutions.

For readers interested in previous posts on this topic, here is a small collection of recent related discussions:

• The limitations of (->)/2 were recently alluded to in understanding the reif library #1924 (comment).
• Sticking to the toplevel instead of using impure output was suggested in clpz and label #1937 (comment).
• The non-existing need for using (=..)/2 in cases like this was pointed out in passing predicates to a module predicate #1951 (comment).

To benefit most from Prolog, you must keep to its pure monotonic core. Try to think in terms of relations and use pure predicates to state what holds. The link to a nice enumeration and classification of pure predicates was recently posted in #1937 (reply in thread). A small number of such predicates suffices to express a great number of Prolog programs with nice declarative properties that we can benefit from when debugging and reasoning about our code. If you use constructs outside this subset, then you do not benefit from these properties, and thus miss a key attraction of logic programming.

[triska]

(==)/2 is another example of a predicate that is not monotonic. For instance:

?- X == Y.
   false.

Yet, adding constraints yields new solutions:

?- X = a, Y = a, X == Y.
   X = a, Y = a.

So, using (==)/2 will destroy desirable logical properties. I think your code can often be improved by severely restricting the set of predicates you are using.

[mvolkmann]

The purpose of the demo goal is only to demonstrate my use of tfilter. I don't expect to reason about demo or run it in multiple directions. Originally I had it using write to output the resulting list. Do you feel it is always wrong write such demo rules? I guess if I don't include examples like that, all I can do is suggest code that is to be run from a top level. I really wanted to provide a single code snippet that people can copy into a source file, run it, and see some result to confirm the operation of the code. But I gather you feel that is a bad idea.

[triska]

I would suggest to use and show only predicates from the pure monotonic core of Prolog, especially if you are showing Prolog to beginners. This is where actual programming in logic is possible.

The interesting aspect of pure Prolog is that you can reason logically about your code and even automatically explain why something is the case or not the case, based on code fragments such as generalizations and failure slices. This works as long as you ensure that logical properties are preserved in your code. Using impure predicates destroys these properties.

Note that copying and pasting a query on the toplevel of a running Prolog process is easier than copying, pasting and consulting a program and then also having to run a query on top of that. You could maybe consider setting up a development environment that makes posting queries easier. For instance, you can run queries directly from Emacs with ediprolog, as described in the README: https://github.com/mthom/scryer-prolog/#development-environment .

[mvolkmann]

I wish it was easy to copy definitions of predicates into the top level. I know you can do that using [user]., but then I'd have to explain about pressing ctrl-d to get back to the top level where the predicates can be exercised. For any non-trivial examples it seems I can't get away from the need to copy code into a source file and then run it with a command like scry -g demo my_example.pl. If I omit the demo rule from the code then two copies are required, one to copy definitions into a source file and one to copy queries into the top level. That's why I have tended toward having complete examples along with a demo rule so only a single copy operation is required.

I also understand that use of emacs is recommended when writing Prolog code. But it's a tall order to expect someone to learn both Prolog and emacs. I've been doing all my work in Neovim because I'm a long time Vim user.

I feel like there is a tension between learning Prolog for the sake of learning about logic program and learning Prolog to accomplish a task. Sticking to the pure monotonic core seems great for learning about logic programming, but is perhaps not particularly productive when trying to write code that needs to communicate with the world outside of the top level.

[UWN]

What I want to express is the recommended way to ...

If you want to use library(reif) first read the paper Indexing dif/2 whose reference you find directly in src/lib/reif.pl. In it, a certain convention is used that you chose to ignore. I tried to explain it to you in previous questions. All in vain. Also the paper explains why the traditional if-then-else is so limited. You use it again without any precaution.

[pmoura]

I also understand that use of emacs is recommended when writing Prolog code. But it's a tall order to expect someone to learn both Prolog and emacs. I've been doing all my work in Neovim because I'm a long time Vim user.

Emacs is indeed recommended by some people. But there are plenty of other choices, varying on their support for Prolog programming. See e.g. https://github.com/LogtalkDotOrg/logtalk3/tree/master/coding for other options. Some systems provide their own IDE (e.g. ECLiPSe, SICStus Prolog, SWI-Prolog, ...).

I feel like there is a tension between learning Prolog for the sake of learning about logic program and learning Prolog to accomplish a task. Sticking to the pure monotonic core seems great for learning about logic programming, but is perhaps not particularly productive when trying to write code that needs to communicate with the world outside of the top level.

There's certainly life outside Prolog pure monotonic core. Outside the classroom, programmers have long been writing applications whose feasibility and effectiveness require stepping outside that core. For many of those applications, the top-level is irrelevant, not every predicate is required to be a relation, and striving to always write the most general predicate definitions would actually be detrimental. Application requirements rule. Applications don't exist in splendid isolation. They talk with the outside world, connect to databases and services, integrate with existing IT systems. For industry practitioners, Prolog is often used and promoted as a general purpose language. The aim is not to build perfect bridges but usable bridges.