Interpreter Objects

The execution of a Prolog goal is an activity. Since Prolog goals are non-deterministic their activity will leave some trace which is beyond the side effects of the Prolog goals themselves. The trace will be some data structure suitable for backtracking. The interpreter objects circle around this data structures.

The interplay between the interpreter and an application poses various challenges. These challenges can be summarized as follows:

The following interaction diagram highlights the aforementioned requirements. We see a shared knowledge base and two threads. The first thread performs a call-in which terminates normally. The second thread performs a call-in, a call-out, a call-in and then throws a program exception which is only caught back in the application:

Picture 5: Interpreter Challenges

Object oriented technology is quite suitable to provide solutions to the posed challenges. An object can encapsulate state and behaviour. Both are needed for the search procedure. Therefore the first design idea is to have interpreter objects besides the shared knowledge base object. We also postulate light weight call objects for call-ins, so as to avoid creating heavy weight interpreter objects each time we perform a new call-in.

The above error handling and multi-threading and is very much motivated by the facilities already present in the host object-oriented programming language, in particular the Java virtual machine. Error handling is implemented along the Java try/catch statement and we provide a Java class interpreter message for an error term without a Prolog stack trace and a Java class Interpreter exception for an error term with a Prolog stack trace.

The current Java virtual machine supports an operating system model based on processes that do not share the heap, and threads that share the heap and have individual stacks. It would be possible to have micro threads, thus doing context switching inside the Prolog in-terpreter itself. The current product version does not have any support for this although this could be useful for massive multi-agent programming.

The execution flow of a Prolog interpreter can be externally influence by two facilities. A Prolog interpreter has an interrupt mask and a signal. This status of a Prolog interpreter can be changed via the methods setMask() and setSignal() of its controller. When setting the interrupt mask and the signal the target thread will be interrupted. As a result blocked Java calls receive an InterruptedException exception. This allows execution supervision of slave threads by a master thread.