passing predicates to a module predicate

[mvolkmann]

It is possible in Scryer Prolog to pass a list of predicate names to a predicate defined in a module and have that predicate evaluate the predicates whose names are passed to it? Here is a short example to demonstrate what I'm trying to do.

% This is the contents of my_module.pl.
:- module(my_module, [call_predicates/1]).
:- use_module(library(lists)).

call_predicate(P) :-
  Goal =.. [P],
  call(Goal).

call_predicates(Ps) :- maplist(call_predicate, Ps).

% This is the contents of main.pl.
:- use_module(my_module).

first :- write('in first'), nl.

second :- write('in second'), nl.

demo :- call_predicates([first, second]).

When I load main.pl and enter demo. I get error(existence_error(procedure,first/0),first/0)..
I believe this is because my_module.pl cannot see predicates defined in main.pl.
Is there a workaround for this scenario?

[UWN]

The module system is predicate based. That means that predicates are grouped into modules, but functors, atoms are not. So first may refer to predicates first/0 in different modules, depending on the context. And since you did not indicate anything, the current module was assumed. How is this contextual information now introduced?

For many uses, it suffices to declare with a meta_predicate/1 declaration which arguments are rather goals and not regular terms. In 0 meaning just a goal, 1 a goal that lacks one argument etc. And to ensure that things do not get confused, also name variables accordingly. Thus G_0 for a variable representing a single goal, G_1 a goal lacking the last argument etc. See library(lambda) and library(reif).

These meta_predicate/1 declarations introduce a simple type systems with the types term and goal_0, goal_1 ... This system is expressive enough to permit safe cross-referencing for code that conforms to it.

In your case, you want a list of goals. That is not directly supported. So you need to first convert terms to such goals. You might do this explicitly (don't!) or

:- meta_predicate(term2goal_1(1,-)).
term2goal_1(G_1,G_1).

?- term2goal_1(length(L),G_1).
   G_1 = user:length(L).
?- term2goal_1(length(L),G_1), call(G_1,3).
   L = [_A,_B,_C], G_1 = user:length([_A,_B,_C]).

(for each N). Do not, repeat, do not rely on the internal representation using (:)/2. Imagine, this changes from time to time. There are slight differences between systems on this level and from release-to-release.

For most uses, this leads to a quite consistent system. But these meta-arguments are effectively used as input arguments only. However, once you want to use another mode like analyze such arguments directly, things get very messy. In case of doubt, refer there to SICStus and not SWI since SWI was originally based on a different predicate based module system and only later adapted SICStus style while still maintaining backwards compatibility which lead to differences that show in such cases.

---

Just another remark on Goal =.. [P],. For those legitimate uses, there is no need to use (=..)/2. And probably, you have a look at call/2, call/3, ...

[UWN]

Well, it seems you prefer you own conventions.

[mvolkmann]

I really don't prefer my own conventions. You know way more about this than I do. I really want to write my code in a way that experienced Prolog developers will find acceptable. My issue is that I'm still discovering those ways. So please let me know if I'm not writing things in the best way or not naming things well. I am definitely open to suggestions on improving!

[UWN]

So please let me know if I'm not writing things in the best way or not naming things well.

Then read my first comment. You ignored so far:

• to avoid explicit qualification (where possible, but here it is all possible),
• to mark variables that are holding goals explicitly (like G_0), just to ensure that you are not handling it as a normal term

The module system (inherited from Quintus) does not do any checks, so explicit qualification means that you can access anything anywhere. And clean conventions help to keep things (at least in theory) checkable. By ignoring above you will soon end up with hard to maintain code that is not portable between SICStus, SWI, YAP, Scryer, and maybe some other systems.

[mvolkmann]

@UWN Here is my latest version of the code I shared previously. See the questions in the TODO comments. Besides those questions, I'm interested in learning what else you would do differently in this code or what naming changes you recommend.

% This is in main.pl.
:- use_module(library(format)).
:- use_module(my_module).

% This converts a predicate to a namespaced goal
% so it can be passed to call_goals.
:- meta_predicate(predicate_goal(1, -)).
% TODO: The rules "first" and "second" take two arguments,
% TODO: so why can't I use the next line in place of the previous one?
% :- meta_predicate(predicate_goal(2, -, -)).

% TODO: Is there a better name for this?
predicate_goal(G_1, G_1).

first(Expected, Actual) :-
  Expected = "one",
  Actual = "1".

second(Expected, Actual) :-
  Expected = "two",
  Actual = "2".

demo :-
  predicate_goal(first, G_1),
  predicate_goal(second, G_2),
  call_goals([G_1, G_2]).

% This is in my_module.pl.
:- module(my_module, [call_goals/1]).
:- use_module(library(format)).
:- use_module(library(lists)). % for maplist

call_goal(G) :-
  call(G, Expected, Actual),
  format("called ~w and got ~s, ~s~n", [G, Expected, Actual]).

call_goals(Gs) :- maplist(call_goal, Gs).

[UWN]

A suffix _1 of a variable means that this is a goal that lacks one argument. Thus call(G_1, A1) is the complete goal. _2 means two arguments are missing, thus call(G_2, A1, A2) is the complete goal. Numbering without an underscore in front most frequently refers to some differences, in particular if the numbering starts with 0 and ends with no number suffix.

[mvolkmann]

Since my first and second rules each expect two arguments, why can't I use this:

:- meta_predicate(predicate_goal(2, -, -)).

instead of this?

:- meta_predicate(predicate_goal(1, -)).

How do you feel about the name predicate_goal? Would you choose a different name?

[UWN]

Neither the number of missing arguments, nor the directionality can be concluded.

In any case, I think it would be much more helpful for you to first learn Prolog, in particular the pure monotonic part of it. See SO. Here (with this necessary directionality and effective dependence on modes) we are really at the fringes. And before you do not master this inner part, such outer issues just lead to one misunderstanding after the other.

[pmoura]

The following paper may be useful:

@incollection {pmoura12d,
	author = "Paulo Moura",
	title = "{Meta-predicate Semantics}",
	booktitle = {Logic-Based Program Synthesis and Transformation},
	series = {Lecture Notes in Computer Science},
	editor = "Germán Vidal",
	publisher = {Springer Berlin / Heidelberg},
	isbn = {978-3-642-32210-5},
	keyword = {Computer Science},
	pages = {155-172},
	volume = {7225},
	url = {http://dx.doi.org/10.1007/978-3-642-32211-2_11},
	doi = {10.1007/978-3-642-32211-2_11},
	year = {2012}
}

Mail me @ logtalk.org if you want a copy.

[mvolkmann]

@pmoura I emailed you to get the paper. Thanks so much!

[pmoura]

I didn't receive your email. To be clear, use pmoura at logtalk.org.

[mvolkmann]

Ah, I originally emailed [email protected]. I just resent the email to the correct address.

[pmoura]

It is possible in Scryer Prolog to pass a list of predicate names to a predicate defined in a module and have that predicate evaluate the predicates whose names are passed to it? Here is a short example to demonstrate what I'm trying to do.

I have a programming example in Logtalk doing just that (passing a list of predicates to be called in their definition context) at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/examples/metapredicates/goals.lgt

But it uses Logtalk objects instead of Prolog modules. Still, you may find it useful. You can run the example with Scryer Prolog:

$ scryerlgt
...
?- {metapredicates(loader)}.
...
?- simple_client::test_whatever_all.
Hello world!   true.

P.S. You can also run this example with B-Prolog, Ciao Prolog, CxProlog, ECLiPSe, GNU Prolog, JIProlog, LVM, Quintus Prolog, SICStus Prolog, SWI-Prolog, Tau Prolog, Trealla Prolog, XSB, and YAP.