ECL i PS e is a Prolog-based programming system, aimed at the development and deployment of constraint programming applications. It is also used for teaching most aspects of combinatorial problem solving, for example, problem modelling, constraint programming, mathematical programming and search techniques. It uses an extended Prolog as its high-level modelling and control language, complemented by several constraint solver libraries, interfaces to thirdparty solvers, an integrated development environment and interfaces for embedding into host environments. This paper discusses language extensions, implementation aspects, components, and tools that we consider relevant on the way from Logic Programming to Constraint Logic Programming.

No abstract

No abstract

We present an overview of the stack-based memory management techniques that we used in our non-deterministic and-parallel Prolog systems: &-Prolog and DASWAM. We believe that the problems associated with non-deterministic and-parallel systems are more general than those encountered in or-parallel and deterministic and-parallel systems, which can be seen as subsets of this more general case. We develop on the previously proposed "marker scheme", lifting some of the restrictions associated with the selection of goals while keeping (virtual) memory consumption down. We also review some of the other problems associated with the stack-based management scheme, such as handling of forward and backward execution, cut, and roll-backs.

We summarise our study of an important (but rarely examined) aspect of parallel execution in logic programming (LP): memory management, and the closely related issue of scheduling. We examine these issues in the context of implicit and-parallelism in nondeterministic programs, because it presents some of the most general problems (see [8] for justifications). This abstract is a highly condensed versión of [8], and the reader is referred to that paper for details. We use the "sub-tree" (or "multi-sequential" approach), where the computation is divided into "chunks" (tasks) which are worked on by individual processing agents (workers) cooperatively in parallel. To retain much of the sequential efficiency of state of the art sequential LP systems while achieving performance improvements through parallelism, each task is executed by the worker in much the same way as in a sequential implementation, except that parallel work can be made available for other idling workers during such execution. Like in sequential LP systems, efficient memory management of parallel LP systems can be achieved by doing stack-based memory management, though parallelism introduces extra complications. Each worker has its own stack, and the stack of a sequential implementation thus becomes a distributed stack, with its state physically distributed across the various workers' stacks, but logically forming a single stack structure. For non-deterministic and-parallelism, where forking and joining of tasks can occur, additional data structures are needed to link and manage the phy sical distributionof the stack. These structures-markers-form the basis of the marker scheme, first introduced in [2]. Essentially, when each worker is working on a task, it uses its stack in much the same way as a sequential implementation would, but when it finishes the task and picks up another task to work on, a marker is allocated onto the stack to sepárate the memory áreas used by the new task from those used by the oíd one and also to logically link and help manage the various sections of stacks used by the tasks. However, as pointed out in [2], the ability of Prolog to perform search, i.e. backtrack and try different alternative solutions, presents special problems for a distributed stack scheme-the problems of "trapped goals" and "garbage slots" (also referred to as "holes" in or-parallel systems): in a sequential system, backtracking causes the stack to shrink in size, and subsequent execution of an alternative causes the stack to grow again. By the same token, in a distributed stack scheme when a task backtracks, the stack section representing the task first shrinks and then grows again. However, because a worker's stack contains all the stack sections of the tasks it executed, the stack section that is being backtracked may notbe at the top of the stack, and such stack sections are "trapped" by the stack sections following it on the worker's stack.