Did you know ... Search Documentation:
Coroutining using Prolog engines

11 Coroutining using Prolog engines

Where the term coroutine in Prolog typically refer to hooks triggered by attributed variables (section 8.1), SWI-Prolog provides two other forms of coroutines. Delimited continuations (see section 4.9) allow creating coroutines that run in the same Prolog engine by capturing and restarting the continuation. This section discusses engines, also known as interactors. The idea was developed by Paul Tarau Tarau, 2011. The API described in this chapter has been established together with Paul Tarau and Paulo Moura.

Engines are closely related to threads (section 10). An engine is a Prolog virtual machine that has its own stacks and (virtual) machine state. Unlike normal Prolog threads though, they are not associated with an operating system thread. Instead, you ask an engine for a next answer (engine_next/2). Asking an engine for the next answer attaches the engine to the calling operating system thread and cause it to run until the engine calls engine_yield/1 or its associated goal completes with an answer, failure or an exception. After the engine yields or completes, it is detached from the operating system thread and the answer term is made available to the calling thread. Communicating with an engine is similar to communicating with a Prolog system though the terminal. In this sense engines are related to Pengines as provided by library library(pengines), but where Pengines aim primarily at accessing Prolog engines through the network, engines are in-process entities.

Section Index

11.1 Examples using engines
11.1.1 Aggregation using engines
11.1.2 State accumulation using engines
11.1.3 Scalable many-agent applications
11.2 Engine resource usage
11.3 Engine predicate reference
Tags are associated to your profile if you are logged in|Report abuse
Tags:
  • fluents
  • interactors
LogicalCaptain said (2020-12-01T11:06:52):0 upvotes 0 0 downvotes
Picture of user LogicalCaptain.

For Pengines, see

The section on Pengines

Some text fixes needed

"Asking an engine for the next answer attaches the engine to the calling operating system thread"

does that mean that the engine is then animated by the OS thread of the engine caller?

"After the engine yields or completes, it is detached from the operating system thread and the answer term is made available to the calling thread."

So the engine is put on hold as the thread returns to animating the caller.

Also:

"The idea was pinned by Paul Tarau" -> "The idea was penned/developed by Paul Tarau"

Fluents vs Interactors

In the earlier papers, Paul Tarau uses "Fluents" -- but that name is not well chosen. In fact, this is already uses to denote a "changing value" when discussion the frame problem, in particular in the event calculus. Do not use.

From Fluents: A Uniform Extension of Kernel Prolog for Reflection adn Interoperation with External Objects

> We revisit the design of Prolog and propose a simplied built-in system which provides a uniform interface for controlling multiple interpreters and external stateful objects. On top of a simple kernel (Horn Clause Interpreters with LD-resolution) we introduce Fluents, high level stateful objects which empower and simplify logic programming languages through reflection of the underlying interpeter, while providing uniform interoperation patterns with object oriented and procedural languages. > > We design a Fluent class hierarchy which includes first-class stateful objects representing the meta-level Horn Clause Interpreters, file, URL, socket Readers and Writers, as well as composable data structures, with high-level operations mapped to recent iterative constructs in the underlying implementation language. > > Fluents melt naturally in the fabric of Logic Programming languages and can be implemented to recover resources on backtracking or to persist. Their expressiveness is shown by redesigning key components of Prolog's system of built-in predicates and through examples of interoperation with the underlying Java system used as an implementation language.

Later called Interactors.

From Coordination and Concurrency in Multi-Engine Prolog

> In this context we have centered our implementation around logic engine constructs providing an API that supports reentrant instances of the language processor. This has naturally led to a view of logic engines as instances of a generalized family of iterators called Fluents [8], that have allowed the separation of the first-class language interpreters from the multi-threading mechanism, while providing a very concise source-level reconstruction of Prolog’s built-ins. Later we have extended the original Fluents with a few new operations supporting bi-directional, mixed-initiative exchanges between engines, bringing them closer to an agent-oriented view as autonomous logic processors. > > The resulting language constructs, that we have called Interactors, express control, metaprogramming and interoperation with stateful objects and external services.

More references

The reference given in the above text as Tarau 2011:

Paul Tarau: Coordination and concurrency in multi-engine Prolog.

Presentation Slides: https://www.researchgate.net/publication/220994006_Coordination_and_Concurrency_in_Multi-engine_Prolog

Conclusion of the Presentation:

  • by decoupling logic engines and threads, programming language constructs for coordination can be kept simple when their purpose is clear
  • multi-threading for performance is separated from concurrency for expressiveness
  • we keep language interpreters independent of multi-threading
  • our language constructs are particularly well-suited to take advantage of today’s multi-core architectures where keeping busy a relatively small number of parallel execution units is all it takes to get predictable performance gains, while reducing the software risks coming from more complex concurrent execution mechanisms designed with massively parallel execution in mind

Paul Tarau: Logic Engines as Interactors

Paul Tarau: Fluents: A Refactoring of Prolog for Uniform Reflection and Interoperation with External Objects

Paul Tarau: Fluents: A Uniform Extension of Kernel Prolog for Reflection and Interoperation with External Objects

See also

Kernel Prolog: Kernel Prolog is an update of a simple open source Prolog interpreter written by Paul Tarau. It distributes various algorithms like unification and LD-resolution used in evaluation Prolog goals over a hierarchy of lightweight term classes. - http://code.google.com/p/kernel-prolog/

Styla: Styla is lightweight Scala-based Prolog interpreter based on a pure object oriented term hierarchy ... using Paul Tarau's Java-based Kernel Prolog as starting point. - https://code.google.com/archive/p/styla/ http://link.springer.com/chapter/10.1007/3-540-44957-4_82

This discussion: https://groups.google.com/g/comp.lang.prolog/c/JToeE7Read8

A thought

Prolog (unlike Lambda-Prolog or extensions like N-Prolog) does not support "Hypothetical Reasoning" whereby you run a proof "under assumption of" some additional facts (or rules). If the engine can be efficiently loaded with the current Prolog Program easily, then be modified by removing/adding to the fact set or rule set, then you could run queries under this new "assumption-laden program". 🤔🤔🤔