B-Prolog

B-Prolog was a high-performance implementation of the standard Prolog language with several extended features including matching clauses, action rules for event handling, finite-domain constraint solving, arrays and hash tables, declarative loops, and tabling. First released in 1994, B-Prolog is now a widely used CLP system. The constraint solver of B-Prolog was ranked top in two categories in the Second International Solvers Competition, and it also took the second place in P class in the second ASP solver competition and the second place overall in the third ASP solver competition. B-Prolog underpins the PRISM system, a logic-based probabilistic reasoning and learning system. B-Prolog is a commercial product, but it can be used for learning and non-profit research purposes free of charge (since version 7.8 for individual users, including commercial individual users, B-Prolog is free of charge ). B-Prolog is not anymore actively developed, but it forms the basis for the Picat programming language.

Matching clauses
A matching clause is a form of a clause where the determinacy and input/output unifications are denoted explicitly. The compiler translates matching clauses into matching trees and generates indexes for all input arguments. The compilation of matching clauses is much simpler than that of normal Prolog clauses because no complex program analysis or specialization is necessary; and the generated code tends to be more compact and faster. The B-Prolog compiler and most of the library predicates are written in matching clauses.

A matching clause takes the following form:

where  is an atomic formula,   and   are two sequences of atomic formulas. is called the head,  the guard, and   the body of the clause. No call in  can bind variables in   and all calls in   must be in-line tests. In other words, the guard must be flat. The following gives an example predicate in matching clauses that merges two sorted lists:

The cons  occurs in both the head and the body of the third clause. To avoid reconstructing the term, we can rewrite the clause into the following:

The call  in the guard matches   against the pattern.

Action rules
The lack of a facility for programming "active" sub-goals that can be reactive to the environment has been considered one of the weaknesses of logic programming. To overcome this, B-Prolog provides a simple and yet powerful language, called Action Rules (AR), for programming agents. An agent is a subgoal that can be delayed and can later be activated by events. Each time an agent is activated, some action may be executed. Agents are a more general notion than delay constructs in early Prolog systems and processes in concurrent logic programming languages in the sense that agents can be responsive to various kinds of events including instantiation, domain, time, and user-defined events.

An action rule takes the following

where  is a pattern for agents,   is a sequence of conditions on the agents,   is a set of patterns for events that can activate the agents, and   is a sequence of actions performed by the agents when they are activated. When the event pattern  together with the enclosing braces is missing, an action rule degenerates into a matching clause.

A set of built-in events is provided for programming constraint propagators and interactive graphical user interfaces. For example,  is an event that is posted when the variable   is instantiated. A user program can create and post its own events and define agents to handle them. A user-defined event takes the form of  where   is a variable, called a suspension variable, that connects the event with its handling agents, and   is a Prolog term that contains the information to be transmitted to the agents. The built-in  posts the event.

Consider the following examples:

The agent  echoes whatever message it receives. For example,

outputs the message  followed by. The agent  responds to time events from the timer. Each time it receives a time event, it prints the message. For example,

creates a timer that posts a time event every second and creates an agent  to respond to the events. The loop after the agent is needed to make the agent perpetual.

AR has been found useful for programming simple concurrency, implementing constraint propagators, and developing interactive graphical user interfaces. It has served as an intermediate language for compiling Constraint Handling Rules (CHR) and Answer Set Programs (ASP).

CLP(FD)
Like many Prolog-based finite-domain constraint solvers, B-Prolog's finite-domain solver was heavily influenced by the CHIP system. The first fully-fledged solver was released with B-Prolog version 2.1 in March 1997. That solver was implemented in an early version of AR, called delay clauses. During the past decade, the implementation language AR has been extended to support a rich class of domain events (, , , and ) for programming constraint propagators and the system has been enriched with new domains (Boolean, trees, and finite sets), global constraints, and specialized fast constraint propagators. Recently, the two built-ins  and   have been extended to allow positive and negative table (also called extensional) constraints.

Thanks to the employment of AR as the implementation language, the constraint solving part of B-Prolog is relatively small (3800 lines of Prolog code and 6000 lines of C code, including comments and spaces) but its performance is very competitive. The AR language is open to the user for implementing problem-specific propagators. For example, the following defines a propagator for maintaining arc consistency for the constraint. Whenever an inner element  is excluded from the domain of , this propagator is triggered to exclude  , the counterpart of  , from the domain of. For the constraint, we need to generate two propagators, namely,   and  , to maintain the arc consistency. In addition to these two propagators, we also need to generate propagators for maintaining interval consistency since no  event is posted if the excluded value happens to be a bound. The constraint needs to be preprocessed to make it arc consistent before the propagators are generated.

Arrays and the array subscript notation
In B-Prolog, the maximum arity of a structure is 65535. This entails that a structure can be used as a one-dimensional array, and a multi-dimensional array can be represented as a structure of structures. To facilitate creating arrays, B-Prolog provides a built-in, called , where   must be an uninstantiated variable and   a list of positive integers that specifies the dimensions of the array. For example, the call  binds   to a two dimensional array whose first dimension has 10 elements and second dimension has 20 elements. All the array elements are initialized to be free variables.

The built-in predicate  can be used to access array elements, but it requires a temporary variable to store the result, and a chain of calls to access an element of a multi-dimensional array. To facilitate accessing array elements, B-Prolog supports the array subscript notation, where   is a structure and each   is an integer expression. This common notation for accessing arrays is, however, not part of the standard Prolog syntax. To accommodate this notation, the parser is modified to insert a token  between a variable token and. So, the notation  is just a shorthand for. This notation is interpreted as an array access when it occurs in an arithmetic expression, a constraint, or as an argument of a call to. In any other context, it is treated as the term itself. The array subscript notation can also be used to access elements of lists. For example, the  predicate can be defined as follows:

Loops with foreach and list comprehension
Prolog relies on recursion to describe loops. The lack of powerful loop constructs has arguably made Prolog less acceptable to beginners and less productive to experienced programmers because it is often tedious to define small auxiliary recursive predicates for loops. The emergence of constraint programming constructs such as CLP(FD) has further revealed this weakness of Prolog as a modeling language. B-Prolog provides a built-in, called, for iterating over collections and the list comprehension notation for constructing lists.

The  built-in has a very simple syntax and semantics. For example,

outputs four tuples,  ,  , and. Syntactically,  is a variable-length call whose last argument specifies a goal to be executed for each combination of values in a sequence of collections. A  call may also give a list of variables that are local to each iteration and a list of accumulators that can be used to accumulate values from each iteration. With accumulators, we can use  to describe recurrences for computing aggregates. Recurrences have to be read procedurally and thus do not fit well with Prolog. For this reason, we adopt the list comprehension notation from functional languages. A list comprehension is a list whose first element has the functor ' '. A list of this form is interpreted as a list comprehension in calls to  and arithmetic constraints. For example, the query

binds  to the list. A list comprehension is treated as a  call with an accumulator in the implementation.

Calls to  and list comprehensions are translated into tail-recursive predicates. Therefore, there is no or little penalty of using these constructs compared with using recursion.

The loop constructs considerably enhance the modeling power of CLP(FD). The following gives a program for the N-queens problem in B-Prolog:

The array notation on lists helps shorten the description. Without it, the  loop in the program would have to be written as follows:

where  and   are declared local to each iteration. The following gives a program for the N-queens problem, which uses a Boolean variable for each square on the board.

Tabling
Tabling has been found increasingly important for not only helping beginners write workable declarative programs but also developing real-world applications such as natural language processing, model checking, and machine learning applications. B-Prolog implements a tabling mechanism, called linear tabling, which is based on iterative computation of looping subgoals rather than suspension of them to compute the fixed points. The PRISM system, which heavily relies on tabling, has been the main driving force for the design and implementation of B-Prolog's tabling system.

The idea of tabling is to memorize the answers to tabled calls and use the answers to resolve subsequent variant calls. In B-Prolog, as in XSB, tabled predicates are declared explicitly by declarations in the following form:

For example, the following tabled predicate defines the transitive closure of a relation as given by.

With tabling, any query to the program is guaranteed to terminate as long as the term sizes are bounded.

By default, all the arguments of a tabled call are used in variant checking and all answers are tabled for a tabled predicate. B-Prolog supports table modes, which allow the system to use only input arguments in variant checking and table answers selectively. The table mode declaration

instructs the system how to do tabling on, where  , called a cardinality limit, is an integer which limits the number of answers to be tabled, and each   is a mode which can be  ,  ,   (input), or   (output). An argument with the mode  or   is assumed to be output. If the cardinality limit  is , it can be omitted with the preceding ' '.

Table modes are very useful for declarative description of dynamic programming problems. For example, the following program encodes the Dijkstra's algorithm for finding a path with the minimum weight between a pair of nodes.

The table mode states that only one path with the minimum weight is tabled for each pair of nodes.