SICStus Prolog has evolved for nearly 25 years. This is an appropriate point in time for revisiting the main language and design decisions, and try to distill some lessons. SICStus Prolog was conceived in a context of multiple, conflicting Prolog dialect camps and a fledgling standardization effort. We reflect on the impact of this effort and role model implementations on our development. After summarizing the development history, we give a guided tour of the system anatomy, exposing some designs that were not published before. We give an overview of our new interactive development environment, and describe a sample of key applications. Finally, we try to identify key good and not so good design decisions.
SICStus Prolog 1 is a Prolog system that has evolved for nearly 25 years. In this article, we revisit the factors affecting the choice of language dialects and APIs, and summarize the more important developments that have taken place over this time period. We also give an in-depth description of the anatomy of the system and its development environment. Some key applications are briefly described. Several design choices that were never published before are described herein. We reflect on these choices, and try to learn some lessons.
The rest of the article is structured as follows. In Section 2, we review and motivate the main phases of development. In Section 3, we give our perspective on two important role models for the SICStus Prolog language, APIs and implementation: the Prolog standardization effort, and Quintus Prolog. In Section 4, we describe the parts of the system that are the most interesting from a design and implementation point of view, going into details where warranted. In Section 5, we describe our Integrated Development Environment (SPIDER). In Section 6, we briefly describe some key applications. Finally, we conclude with some lessons learned from the whole endeavor. appear in SICStus Prolog 4.1. Also, it has been clear for a long time that users have come to expect more from an integrated development environment than what Emacs can provide. After a considerable implementation effort by the second author, we release SPIDER, our Eclipse-based IDE.
SICStus Prolog was conceived in a context of multiple, conflicting Prolog dialect camps and a fledgling standardization effort. The first author’s first encounter with a Prolog system was with DECsystem-10 Prolog i.e. with the Edinburgh tradition, so there was never any question which camp to align to. Later, Quintus Prolog arrived on the scene in the same tradition, by the same lead designer, and emerged as the de-facto standard, due to its industrial quality and speed. Quintus Prolog was also among the first systems to provide designs for features such as foreign language interface, embeddability, customization through hook predicates and functions, and module system. Since Quintus Prolog seemed to be doing everything right, it seemed pointless to try to come up with alternative designs for these features. Instead, in the design of SICStus Prolog, we opted for the “imitation is the sincerest (form) of flattery” principle (Colton 1832).
The ISO Prolog standardization effort started late, too late. The Prolog dialects had already diverged: basically, there were as many dialects as there were implementations, although the Edinburgh tradition, which had grown out of David H.D. Warren’s work, was always the dominant one. Every vendor had already invested too much effort and acquired too large a customer base to be prepared to make radical changes to syntax and semantics. Instead, every vendor would defend his own dialect against such radical changes. Finally, after the most vehement opposition had been worn down in countless acrimonious committee meetings, a compromise document that most voting countries could live with was submitted for balloting and was approved.
Although far from perfect, we wanted to promote the standard. At the same time, our users had already developed vast amounts of non-compliant code, which we had no right to break. Our solution to this dilemma was to provide a dual dialect system, SICStus Prolog 3.
This section is more or less a white paper of the current system architecture, covering the parts of the system that are the most interesting from a design and implementation point of view. This description is necessarily incomplete, and the omission of some system component does not at all mean that its design and implementation is trivial or uninteresting.
Before and especially after our take-over of Quintus Prolog, a lot of designs and assets have migrated into SICStus Prolog, including: instruction set details, tagging scheme, structs and objects modules, foreign language interface, message and query systems, and memory manager. So in the rest of this article, we will not credit Quintus Prolog each time.
Prolog code can be executed in three different modes, and each variant comes with its pros and cons.
Interpreted. Prolog clauses are stored in a form that is close to the source code, and are executed by an interpreter written either in the host language or in Prolog itself. Such an interpreted is an excellent base for debuggers, and is virtually necessary for bootstrapping purposes even in the presence of a compiler. The main disadvantage is slow execution. Native code. Early, successful implementations such as (Warren 1979;Farkas et al. 1994) showed that Prolog is amenable to compilation to native machine code with modest to good execution speed. Later work (Taylor 1991;Van Roy and Despain 1992) demonstrated that excellent execution speed can be achieved with global analysis. The main drawbacks of native code comp
This content is AI-processed based on open access ArXiv data.
