|Did you know ...||Search Documentation:|
|Understanding the Pengine concept|
Maybe we should try to tell a story that most Prolog programmers can understand? This is how I believe you can think about it in very simple terms: Suppose you are sitting in front of two computers A and B, both running a terminal/shell. You can start Prolog in the shell of A by executing swipl. You can also start Prolog in the shell of B by executing swipl on that computer. In a sense, you have created two Prolog engines, both of them waiting for your next commands.
Now you can ask A a query, or start some kind of other process, and then turn to B and (say) ask another query. You are in control, since you can choose what to do and in which Prolog - A or B - guided by what is printed on the two screens.
Fortunately, equipped with the pengines library you don't need two
computers or two SWI-Prolog main processes to program in this way.
You can run
in the same shell. Better yet, it doesn't
even have to be you doing the programming! Instead, you can write a
program that based on what comes back from A and/or B sends the next
command (or whatever needs to be done) to A and/or to B.
Another way to program with Pengines is to call a goal on B if your are on A. That's what you do with pengine_rpc/3. This should be even easier to grasp than the rest, since you can think of it as a kind of call/1 that calls its (possibly non-deterministic) goal not locally but remotely, and in the Prolog context of the remote pengine server (perhaps also in union with code (if any) that you to sent along).
pengine_rpc/3 is defined in terms of the other (core) pengine predicates. That is also kind of nice, I think.