Extra-logical Features Research Articles

Cuts and side-effects in and-or parallel Prolog

Practical Prolog programs usually contain extra-logical features like cuts, side-effects, and database manipulating predicates. In order to exploit implicit parallelism from real applications while preserving sequential Prolog semantics, a parallel logic programming system should necessarily support these features. In this paper we show how Prolog's extra-logical features can be supported in an and-or parallel logic programming system. We show that to support extra-logical features an and-or parallel logic programming system should recompute the solutions to independent goals instead of sharing them. We describe an abstraction called the composition tree for representing and-or parallel execution with recomputation. We introduce the notion of “focal-leftmostness” in the composition tree and use it for deriving complete and efficient methods for supporting extra-logical predicates in and-or parallel logic programming systems based on the composition tree abstraction.

A mathematical definition of full Prolog

The paper provides a mathematical yet simple model for the full programming language Prolog, as apparently intended by the ISO draft standard proposal. The model includes all control constructs, database operations, solution collecting predicates and error handling facilities, typically ignored by previous theoretical treatments of the language. We add to this the ubiquitous boxmodel debugger. The model directly reflects the basic intuitions underlying the language and can be used as a primary mathematical definition of Prolog. The core of the model has been applied for mathematical analysis of implementations, for clarification of disputable language features and for specifying extensions of the language in various directions. The model may provide guidance for extending the established theory of logic programming to the extralogical features of Prolog.

Cut and side-effects in a data-driven implementation of Prolog

A number of data-driven execution models have been proposed for parallel execution of logic programs8, 12, 9, 3) LogDf is an abstract data-driven execution model for pure logic programs3) which has shown promising performance during simulations. However, the original model lacks support for extra logical features such as cut and side-effects, which are needed to execute Prolog programs. This paper describes a scheme that has been incorporated into the LogDf model to support cut and side-effects. The main component of the scheme is a data structure, called a flat, non-strict S-Stream, which maintains strict ordering of multiple solutions, and, at the same time, allows simultaneous modification by several actors. This ordering corresponds to the order in which solutions would be produced in a sequential system and is necessary to implement cut and side-effects. The correct synchronization and ordering of operations on the cells of an S-Stream is ensured by the use of I-structure memory.1) The descriptor based token coloring mechanism in the LogDf provides convenient support for maintaining the scope information associated with cuts. An efficient garbage collection strategy is also proposed.

A fine-grained account of Prolog execution for teaching and debugging

A clear and consistent execution model of any programming language can lay the foundations not only for a good leaming experience, but also for a smoother design/edit/run/debug cycle. In this paper, we describe our attempt to construct precisely such a model for the logic programming language Prolog, based upon a notational extension of logic programming's traditional AND/OR trees. Our extension, called the “AORTA” diagram, is an And/OR Tree, Augmented to include invocation history “status boxes” at each node. This augmentation makes it possible to present a graphical view of Prolog execution which is very compact, yet which contains complete details of unification and control history, including multiple (backtracking) invocations and extra-logical features such as the cut. The paper describes our fine-grained view of Prolog execution in detail, and argues that this fine-grained view can readily be integrated into a coarse-grained model such as thatrequired for understanding the execution of very large programs. Indeed, our notation is already in use across a range of media, including textbook diagrams, video animations, and a graphical tracing and debugging facility running on modem graphics workstations.