WI-Prolog has been designed and implemented to get a Prolog implementation which can be used
for experiments with logic programming and the relation to other programming paradigms. The inten-
tion was to build a Prolog environment which offers enough power and flexibility to write substantial
applications, but is straightforward enough to be modified for experiments with debugging, optimi-
sation or the introduction of non-standard data types. Performance optimisation is limited due to the
main objectives: portability (SWI-Prolog is entirely written in C and Prolog) and modifiability.
SWI-Prolog is based on a very restricted form of the WAM (Warren Abstract Machine) described
in [Bowen & Byrd, 1983] which defines only 7 instructions. Prolog can easily be compiled into this
language and the abstract machine code is easily decompiled back into Prolog. As it is also possible
to wire a standard 4-port debugger in the WAM interpreter there is no need for a distinction between
compiled and interpreted code. Besides simplifying the design of the Prolog system itself this ap-
proach has advantages for program development: the compiler is simple and fast, the user does not
have to decide in advance whether debugging is required and the system only runs slightly slower
when in debug mode. The price we have to pay is some performance degradation (taking out the
debugger from the WAM interpreter improves performance by about 20%) and somewhat additional
memory usage to help the decompiler and debugger.
SWI-Prolog extends the minimal set of instructions described in [Bowen & Byrd, 1983] to im-
prove performance. While extending this set care has been taken to maintain the advantages of de-
compilation and tracing of compiled code. The extensions include specialised instructions for unifi-
cation, predicate invocation, some frequently used built-in predicates, arithmetic, and control (;/2,
|/2), if-then (->/2) and negation-by-failure (\+/1). SWI-Prolog has been used now for many years.
The application range includes Prolog course material, meta-interpreters, simulation of parallel Pro-
log, learning systems, natural language processing and two large workbenches for knowledge en-
gineering. Although we experienced rather obvious and critical bugs can remain unnoticed for a
remarkable long period, we assume the basic Prolog system is fairly stable. Bugs can be expected in
infrequently used built-in predicates.There are a number of reasons why you better choose a commercial Prolog system, or another aca-demic product:
• SWI-Prolog is not supported
Although I usually fix bugs shortly after a bug report arrives, I cannot promise anything. Now
that the sources are provided, you can always dig into them yourself.
• Memory requirements and performance are your first concerns
A number of commercial compilers are more keen on memory and performance than SWI-
Prolog. I do not wish to sacrifice some of the nice features of the system, nor its portability to
compete on raw performance.
• You need features not offered by SWI-Prolog
In this case you may wish to give me suggestions for extensions. If you have great plans, please
contact me (you might have to implement them yourself however).
On the other hand, SWI-Prolog offers some nice facilities:
• Nice environment
This includes ‘Do What I Mean’, automatic completion of atom names, history mechanism and
a tracer that operates on single key-strokes. Interfaces to some standard editors are provided
(and can be extended), as well as a facility to maintain programs (see make/0).
• Very fast compiler
Even very large applications can be loaded in seconds on most machines. If this is not enough,
there is a Quick Load Format that is slightly more compact and loading is almost always I/O
bound.
• Transparent compiled code
SWI-Prolog compiled code can be treated just as interpreted code: you can list it, trace it, etc.
This implies you do not have to decide beforehand whether a module should be loaded for
debugging or not. Also, performance is much better than the performance of most interpreters.
• Profiling
SWI-Prolog offers tools for performance analysis, which can be very useful to optimise pro-
grams. Unless you are very familiar with Prolog and Prolog performance considerations this
might be more helpful than a better compiler without these facilities.
• Flexibility
SWI-Prolog can easily be integrated with C, supporting non-determinism in Prolog calling C as
well as C calling Prolog (see section 5. It can also be embedded embedded in external programs
(see section 5.7). System predicates can be redefined locally to provide compatibility with other
Prolog systems.
• Integration with XPCE
SWI-Prolog offers a tight integration to the Object Oriented Package for User Interface De-
velopment, called XPCE [Anjewierden & Wielemaker, 1989]. XPCE allows you to implement
graphical user interfaces that are source-code compatible over Unix/X11 and Windows