Abstract. A lightweight approach to debugging functional logic programs by observations is presented, implemented for the language Curry. The Curry Object Observation System (COOSy) comprises a portable library plus a viewing tool. A programmer can observe data structures and functions by annotating expressions in his program. The possibly partial values of observed expressions that are computed during program execution are recorded in a trace file, including information on non-deterministic choices and logical variables. A separate viewing tool displays the trace content. COOSy covers all aspects of modern functional logic multiparadigm languages such as lazy evaluation, higher order functions, non-deterministic search, logical variables, concurrency and constraints. Both use and implementation of COOSy are described. 1

. We present a general framework for the declarative debugging of functional logic programs, which is valid both for eager as well as lazy programs. We associate with our programs a semantics based on a (continuous) immediate consequence operator which models computed answers. Then we show that, given the intended specification of a program P , it is possible to check the correctness of P by a single step of the immediate consequence operator. Our methodology can be used both for bottom-up as well as top-down (abstract) debugging. It is particularly suitable when pure functional logic programs are used as specification of other more efficient functional logic programs, going back to the origins, i.e. looking at declarative languages as languages for both rapid prototyping and implementation. We also present a more effective methodology which is based on abstract interpretation. By approximating the intended specification of the success set we derive a finitely terminating d...

This paper formally presents a model of tracing for functional programs based on a small-step operational semantics. The model records the computation of a functional program in a graph which can be utilised for various purposes such as algorithmic debugging. The main contribution of this paper is to prove the correctness of algorithmic debugging for functional programs based on the model. Although algorithmic debugging for functional programs is implemented in several tracers such as Hat, the correctness has not been formally proved before. The difficulty of the proof is to find a suitable induction principle and a more general induction hypothesis. 1

Abstract. Functional values are used naturally in higher order functional programs, as they are commonly passed around or returned by other function. As such any debugger for these languages must be capable of conveying information about functional values to the user. Current debuggers are limited to displaying the name of the function, or a partial application. In this paper we study two alternative methods of displaying functional values, and their effect on a popular debugging method (Algorithmic Debugging). 1

We describe the design of a declarative debugger for diagnosing wrong answers in lazy functional logic programs with polymorphic type discipline. Following a known technique, the debugger is based on a program transformation: transformed programs return the computation trees needed for debugging, in addition to the results expected by source programs. Thanks to a careful specication of the translation, we are able to prove its correctness w.r.t. well-typing and program semantics.

Abstract In non-strict functional programming languages such as Haskell, it happens often that some parts of a program are not evaluated because their values are not demanded. In practice, those unevaluated parts are often replaced by a placeholder (e.g. _) in order to keep the trace size smaller. In the process of algorithmic debugging, one needs to answer several questions in order to locate a program fault. Replacing unevaluated parts makes these questions shorter and semantically clearer. In this paper, we present a formal model of tracing in which unevaluated parts are replaced by the symbol _. The most important property, the correctness of algorithmic debugging, is proved. 1

Abstract We present a generic scheme for the abstract debugging of functional-logic programs. We associate to our programs a semantics based on a (continuous) immediate consequence operator, P �R�, which models correctly the typical cogent features of modern functional-logic languages (non-deterministic, non-strict functions defined by non-confluent programs and call-time choice behaviour). Then, we develop an effective debugging methodology which is based on abstract interpretation: by approximating the intended specification of the semantics of R we derive a finitely terminating bottom-up diagnosis method, which can be used statically. Our debugging framework does not require the user to either provide error symptoms in advance or answer questions concerning program correctness. 1

This work is motivated by the fact that a “compact ” semantics for functional logic languages, which is essential for the development of efficacious semantics-based program manipulation tools (e.g. automatic program analyzers and debuggers), does not exist. The operational or the rewriting logic semantics that are most commonly considered in functional logic are unnecessarily oversized, as they contains many “semantically useless ” elements that can be retrieved from a smaller set of “basic” elements. Therefore, in this article, we present a compressed, goalindependent bottom-up fixpoint semantics that is correct and minimal w.r.t. answers computed for Curry expressions. We believe that the compactness of the semantics makes it particularly suitable for applications. Actually, our semantics can be finite whereas the big-step semantics is generally not, and even when both semantics are infinite, the fixpoint computation of our semantics produces fewer

The tracer Hat records in a detailed trace the computation of a program written in the lazy functional language Haskell. The trace can then be viewed in various ways to support program comprehension and debugging. The trace was named the augmented redex trail. Its structure was inspired by standard graph rewriting implementations of functional languages. Here we describe a model of the trace that captures its essential properties and allows formal reasoning. The trace is a graph constructed by graph rewriting but goes beyond simple term graphs. Although the trace is a graph whose structure is independent of any rewriting strategy, we define the trace inductively, thus giving us a powerful method for proving its properties. Keywords: Tracing, debugging, augmented redex trail, Haskell. 1

This report describes BUGGY, a declarative debugger for functional logic programs. The program includes three phases. The first one corresponds to the introduction of the incorrect programs and intended semantics. The second phase search the errors in the program and their corrections. The last phase searches uncovered equations and their corrections