Introduction

XSB is a research-oriented Logic Programming system for Unix and Windows-based platforms. In addition to providing all the functionality of Prolog, XSB contains several features not usually found in Logic Programming systems, including

• Evaluation according to the Well-Founded Semantics [49] through full SLG resolution;
• Constraint handling for tabled programs based on an engine-level implementation of annotated variables and a package, clpqr for handling real constraints;
• A variety of indexing techniques for asserted code and both backtrackable and non-backtrackable updates to asserted code.
• A set of mature packages, to extend XSB to evaluate F-logic [28] through the FLORA package, to manage ontologogies through the Cold Dead Fish package, and to support literate programming through the xsbdoc package, among other features.
• A number of interfaces to other software systems, such a C, Java, Perl, ODBC, SModels [36], and Oracle.
• A compiled HiLog implementation;
• Extensive pattern matching packages, and interfaces to libwww routines, all of which are especially useful for Web applications.
• A novel transformation technique called unification factoring that can improve program speed and indexing for compiled code;
• Preprocessors and Interpreters so that XSB can be used to evaluate programs that are based on advanced formalisms, such as extended logic programs (according to the Well-Founded Semantics [2]); Generalized Annotated Programs [29].
• Source code availability for portability and extensibility.

Though XSB can be used as a Prolog system^1.1, we avoid referring to XSB as such, because of the availability of SLG resolution and the handling of HiLog terms. These facilities, while seemingly simple, significantly extend its capabilities beyond those of a typical Prolog system. We feel that these capabilities justify viewing XSB as a new paradigm for Logic Programming.

To understand the implications of SLG resolution [12], recall that Prolog is based on a depth-first search through trees that are built using program clause resolution (SLD). As such, Prolog is susceptible to getting lost in an infinite branch of a search tree, where it may loop infinitely. SLG evaluation, available in XSB, can correctly evaluate many such logic programs. To take the simplest of examples, any query to the program:

:- table ancestor/2.

ancestor(X,Y) :- ancestor(X,Z), parent(Z,Y).
ancestor(X,Y) :- parent(X,Y).

will terminate in XSB, since ancestor/2 is compiled as a tabled predicate; Prolog systems, however, would go into an infinite loop. The user can declare that SLG resolution is to be used for a predicate by using table declarations, as here. Alternately, an auto_table compiler directive can be used to direct the system to invoke a simple static analysis to decide what predicates to table (see Section 3.8.4). This power to solve recursive queries has proven very useful in a number of areas, including deductive databases, language processing [30,31], program analysis [17,13,7], model checking [38] and diagnosis [24]. For efficiency, we have implemented SLG at the abstract machine level so that tabled predicates will be executed with the speed of compiled Prolog. We finally note that for definite programs SLG resolution is similar to other tabling methods such as OLDT resolution [48] (see Chapter 5 for details).

Example 1.0.1   The use of tabling also makes possible the evaluation of programs with non-stratified negation through its implementation of the well-founded semantics [49]. When logic programming rules have negation, paradoxes become possible. As an example consider one of Russell's paradoxes -- the barber in a town shaves every person who does not shave himself -- written as a logic program.

 
:- table shaves/2.

shaves(barber,Person):- person(Person), tnot(shaves(Person,Person)).
person(barber).
person(mayor).

Logically speaking, the meaning of this program should be that the barber shaves the mayor, but the case of the barber is trickier. If we conclude that the barber does not shave himself our meaning does not reflect the first rule in the program. If we conclude that the barber does shave himself, we have reached that conclusion using information beyond what is provided in the program. The well-founded semantics, does not treatshaves(barber,barber) as either true or false, but as undefined. Prolog, of course, would enter an infinite loop. XSB's treatment of negation is discussed further in Chapter 5.

The second important extension in XSB is support of HiLog programming [10,44]. HiLog allows a form of higher-order programming, in which predicate ``symbols'' can be variable or structured. For example, definition and execution of generic predicates like this generic transitive closure relation are allowed:

closure(R)(X,Y) :- R(X,Y).
closure(R)(X,Y) :- R(X,Z), closure(R)(Z,Y).

where closure(R)/2 is (syntactically) a second-order predicate which, given any relation R, returns its transitive closure relation closure(R). With XSB, support is provided for reading and writing HiLog terms, converting them to or from internal format as necessary (see Section 4.2). Special meta-logical standard predicates (see Section 6.5) are also provided for inspection and handling of HiLog terms. Unlike earlier versions of XSB (prior to version 1.3.1) the current version automatically provides full compilation of HiLog predicates. As a result, most uses of HiLog execute at essentially the speed of compiled Prolog. For more information about the compilation scheme for HiLog employed in XSB see [44].

HiLog can also be used with tabling, so that the program above can also be written as:

:- hilog closure.
:- table apply/3.

closure(R)(X,Y) :- R(X,Y).
closure(R)(X,Y) :- closure(R)(X,Z), R(Z,Y).

as long as the underlying relations (the predicate symbols to which R will be unified) are also declared as Hilog. For example, if a/2 were a binary relation to which the closure predicate would be applied, then the declaration :- hilog a. would also need to be included.

We also note that tabled programs can be used with attributed variables, leading to constraint tabled programs (see Volume 2 of this manual for a discussion of the interfaces to attributed variables).

A further goal of XSB is to provide in implementation engine for both logic programming and for data-oriented applications such as in-memory deductive database queries and data mining [41]. One prerequisite for this functionality is the ability to load a large amount of data very quickly. We have taken care to code in C a compiler for asserted clauses. The result is that the speed of asserting and retracting code is faster in XSB than in any other Prolog system of which we are aware. At the same time, because asserted code is compiled into SLG-WAM code, the speed of executing asserted code in XSB is faster than that of many other Prologs as well. We note however, that XSB does not follow the semantics of assert specified in [33].

Data oriented applications may also require indices other than Prolog's first argument indexing. XSB offers a variety of indexing techniques for asserted code. Clauses can be indexed on a group of arguments or on alternative arguments. For instance, the executable directive index(p/4,[3,2+1]) specifies indexes on the (outer functor symbol of) the third argument or on a combination of (the outer function symbol of) the second and first arguments. If data is expected to be structured within function symbols and is in unit clauses, the directive index(p/4,trie) constructs an indexing trie of the p/4 clauses using a left-to-right traversal through each clause. Representing data in this way allows discrimination of information nested arbitrarily deep within clauses. These modes of indexing can be combined: index(p/4,[3,2+1],trie) creates alternative trie indices beginning with the third argument and with the second and first argument. Using such indexing XSB can efficiently perform intensive analyses of in-memory knowledge bases with millions of facts. Indexing techniques for asserted code are covered in Section 6.10.

For compiled code, XSB offers unification factoring, which extends clause indexing methods found in functional programming into the logic programming framework. Briefly, unification factoring can offer not only complete indexing through non-deterministic indexing automata, but can also factor elementary unification operations. The general technique is described in [16], and the XSB directives needed to use it are covered in Section 3.8.

A number of interfaces are available to link XSB to other systems. In UNIX systems XSB can be directly linked into C programs; in Windows-based system XSB can be linked into C programs through a DLL interface. On either class of operating system, C functions can be made callable from XSB either directly within a process, or using a socket library. XSB can also inter-communicate with Java through the InterProlog interface, ^1.2. XSB can access external data in a variety of ways: through an ODBC interface, through an Oracle interface, or through a variety of mechanisms to read data from flat files. These interfaces are all described in Volume 2 of this manual.

Another feature of XSB is its support for extensions of normal logic programs through preprocessing libraries. In particular, XSB supports a sophisticated object-oriented interface called Flora. Flora is available as an XSB package and is described in its own manual, available from the same site from which XSB was downloaded. In addition, other preprocessing libararies currently supported are Extended logic programs (under the well-founded semantics), F-Logic, and Annotated Logic Programs. These latter libraries are described in Volume 2 of this manual.

Source code is provided for the whole of XSB, including the engine, interfaces and supporting functions written in C, along with the compiler, top-level interpreter and libraries written in Prolog.

It should be mentioned that we adopt some standard notational conventions, such as the name/arity convention for describing predicates and functors, + to denote input arguments, - to denote output arguments, ? for arguments that may be either input or output and # for arguments that are both input and output (can be changed by the procedure). See Section 3.8.4 for more details. Also, the manual uses UNIX syntax for files and directories except when it specifically addresses other operating systems such as Windows.

Finally, we note that XSB is under continuous development, and this document --intended to be the user manual-- reflects the current status (Version 2.5) of our system. While we have taken great effort to create a robust and efficient system, we would like to emphasize that XSB is also a research system and is to some degree experimental. When the research features of XSB -- tabling, HiLog, and Indexing Techniques -- are discussed in this manual, we also cite documents where they are fully explained. All of these documents can be found via the world-wide web or anonymous ftp from {www/ftp}.cs.sunysb.edu, the same host from which XSB can be obtained.

While some of Version 2.5 is subject to change in future releases, we will try to be as upward-compatible as possible. We would also like to hear from experienced users of our system about features they would like us to include. We do try to accommodate serious users of XSB whenever we can. Finally, we must mention that the use of undocumented features is not supported, and at the user's own risk.