This paper describes the Oz Explorer and its implementation. The Explorer is a visual constraint programming tool intended to support the development of constraint programs. It uses the search tree of a constraint problem as its central metaphor. Exploration and visualization of the search tree are userdriven and interactive. The constraints of any node in the tree are available first-class: predefined or user-defined procedures can be used to display or analyze them. The Explorer is a fast and memory efficient tool intended for the development of real-world constraint programs. The Explorer is implemented in Oz using first-class computation spaces. There is no fixed search strategy in Oz. Instead, first-class computation spaces allow to program search engines. The Explorer is one particular example of a user-guided search engine. The use of recomputation to trade space for time makes it possible to solve large real-world problems, which would use too much memory otherwise.

Tableau-based proof systems can be elegantly specified and directly executed by a tabled Logic Programming (LP) system. Our experience with the XMC model checker shows that such an encoding can be used to search for the existence of a proof very efficiently. However, the users of a tableau system are often interested in getting sufficient evidence (in terms of the tableau proof rules) on why a proof does or does not exist. In this paper, we address the problem of constructing such an evidence without introducing any additional computational overhead to the proof search. A tabled LP system maintains a memo table of "lemmas" that were tried and possibly proved during query evaluation. We propose the concept of justifier for extracting sufficient evidence for the truth or falsehood of literals in a logic program, by post-processing the memo tables created during query evaluation. Based on this logic program justifier, we showhow to construct evidence for the presence/absence of tableau in a tableau-based proof system. Weprovide experimental results showing the effectiveness of the justifier in constructing succinct evidence of the evaluation performed by the XMC model checker. Finally we discuss the role of the justifier as a programming abstraction for encoding efficient algorithms as tabled logic programs.

Traces of program executions are a helpful source of information for automated debugging. They, however, usually give a too low level picture of the executed program. Opium, our extendable trace analyser for Prolog, is connected to a "standard" tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions which solve the problems of low-level traces. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specied and implemented within a few days. They show how to use Opium for real applications.

This thesis presents design, application, implementation, and evaluation of computation spaces as abstractions for programming constraint services at a high level. Spaces are seamlessly integrated into a concurrent programming language and make constraintbased computations compatible with concurrency through encapsulation. Spaces are applied

Much work has been done in the areas of and--parallelism and data parallelism in Logic Programs. Such work has proceeded to a certain extent in an independent fashion. Both types of parallelism offer advantages and disadvantages. Traditional (and--) parallel models offer generality, being able to exploit parallelism in a large class of programs (including that exploited by data parallelism techniques). Data parallelism techniques on the other hand offer increased performance for a restricted class of programs. The thesis of this paper is that these two forms of parallelism are not fundamentally different and that relating them opens the possibility of obtaining the advantages of both within the same system. Some relevant issues are discussed and solutions proposed. The discussion is illustrated through visualizations of actual parallel executions implementing the ideas proposed. Keywords: Parallel Logic Programming, And-Parallelism, Data-Parallelism, Fast Task Startup, Scheduling. 1 I...

: Traces of program executions are a helpful source of information for automated debugging. They, however, usually give a too low level picture of the executed program. Opium, our extendable trace analyser for Prolog, is connected to a "standard" tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions which solve the problems of low-level traces. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specified and implemented within a few days. They show how to use Opium for real applications. Key-words: Software Engineering, Auto...

Performance studies of actual parallel systems usually tend to concentrate on the effectiveness of a given implementation. This is often done in the absolute, without quantitave reference to the potential parallelism contained in the programs from the point of view of the execution paradigm. We feel that studying the parallelism inherent to the programs is interesting, as it gives information about the best possible behavior of any implementation and thus allows contrasting the results obtained. We propose a method for obtaining ideal speedups for programs through a combination of sequential or parallel execution and simulation, and the algorithms that allow implementing the method. Our approach is novel and, we argue, more accurate than previously proposed methods, in that a crucial part of the data -- the execution times of tasks -- is obtained from actual executions, while speedup is computed by simulation. This allows obtaining speedup (and other) data under controlled and ideal as...

Abstract not found

Visualization of program executions has been found useful in applications which include education and debugging. However, traditional visualization techniques often fall short of expectations or are altogether inadequate for new programming paradigms, such as Constraint Logic Programming (CLP), whose declarative and operational semantics differ in some crucial ways from those of other paradigms. In particular, traditional ideas regarding flow control and the behavior of data often cannot be lifted in a straightforward way to (C)LP from other families of programming languages. In this paper we discuss techniques for visualizing program execution and data evolution in CLP. We briefly review some previously proposed visualization paradigms, and also propose a number of (to our knowledge) novel ones. The graphical representations have been chosen based on the perceived needs of a programmer trying to analyze the behavior and characteristics of an execution. In particular, we concentrate on...

We provide an overall description of the Ciao multiparadigm programming system emphasizing some of the novel aspects and motivations behind its design and implementation. An important aspect of Ciao is that, in addition to supporting logic programming (and, in particular, Prolog), it provides the programmer with a large number of useful features from different programming paradigms and styles, and that the use of each of these features (including those of Prolog) can be turned on and off at will for each program module. Thus, a given module may be using, e.g., higher order functions and constraints, while another module may be using imperative operations, predicates, Prolog metaprogramming builtins, and concurrency. Furthermore, the language is designed to be extensible in a simple and modular way. Another important aspect of Ciao is its programming environment, which provides a powerful preprocessor (with an associated assertion language) capable of statically finding non-trivial bugs, verifying that programs comply with specifications, and performing many types of program optimizations (including automatic parallelization). Such optimizations produce code that is highly competitive with other dynamic languages or, when the (experimental) optimizing compiler is used, even that of static languages, all while retaining the interactive development environment