Different tracing systems for Haskell give different views of a program at work. In practice, several views are complementary and can productively be used together. Until now each system has generated its own trace, containing only the information needed for its particular view. Here we present the design of a trace that can serve several views. The trace is generated and written to file as the computation proceeds. We have implemented both the generation of the trace and several different viewers. 1

. We describe the design and implementation of a system for tracing computations in a lazy functional language. The basis of our tracing method is a program transformation carried out by the compiler: transformed programs compute the same values as the original, but embedded in functional data structures that also include redex trails showing how the values were obtained. A special-purpose display program enables detailed but selective exploration of the redex trails, with cross-links to the source program. Keywords: debugging, graph reduction, Haskell, program transformation. 1 Introduction 1.1 Why trace functional computations? Functional programming languages have many advantages over the conventional alternative of procedural languages. For example, program construction is more rapid, more modular and less error-prone. Programs themselves are more concise. Yet functional programming systems are not very widely used. There are various reasons for this, but one that crops up time ...

In this paper we compare three systems for tracing and debugging Haskell programs: Freja, Hat and Hood. We evaluate their usefulness in practice by applying them to a number of moderately complex programs in which errors had deliberately been introduced. We identify the strengths and weaknesses of each system and then form ideas on how the systems can be improved further.

We introduce the theoretical basis for tracing lazy functional logic computations in a declarative multi-paradigm language like Curry. Tracing computations is a difficult task due to the subtleties of the underlying operational semantics which combines laziness and non-determinism. In this work, we define an instrumented operational semantics that generates not only the computed values and bindings but also an appropriate data structure—a sort of redex trail—which can be used to trace computations at an adequate level of abstraction. In contrast to previous approaches, which rely solely on a transformation to instrument source programs, the formal definition of a tracing semantics improves the understanding of the tracing process. Furthermore, it allows us to formally prove the correctness of the computed trail. A prototype implementation of a tracer based on this semantics demonstrates the usefulness of our approach.

. Redex trails are histories of functional computations by graph reduction; their main application is fault-tracing. A prototype implementation of a tracer based on redex trails [8] demonstrated the promise of the technique, but was limited in two respects: (1) trails did not record every reduction, only those constructing a new value; (2) even so computing trails was very expensive, particularly in terms of the memory space they occupied. In this paper, we address both problems: complete redex trails provide a full computational record; partial versions of these trails exclude all but selected details, greatly reducing memory costs. We include results of experiments tracing several applications, including a compiler. 1 Introduction Programs do not always work first time. When they fail, programmers cannot always see the reason immediately. Implementors must therefore provide some way of tracing computations. By examining traces, programmers can see not only final results o...

Designing debugging tools for lazy functional programming languages is a complex task which is often solved by expensive tracing of lazy computations. We present a new approach in which the information collected as a trace is reduced considerably (kilobytes instead of megabytes). The idea is to collect a kind of step information for a call-by-value interpreter, which can then efficiently reconstruct the computation for debugging/viewing tools, like declarative debugging. We show the correctness of the approach, discuss a proof-of-concept implementation with a declarative debugger as back end and present some benchmarks comparing our new approach with the Haskell debugger Hat.

Despite these expected benefits, declarative debugging is not yet widely used in practice to find real bugs. There are three main reasons for this: 1. Most previous declarative debuggers only support a subset of the features of their target language that is not sufficient to express real programs. 2. Previous declarative debuggers do not scale well when applied to problems with large search spaces. 3. Previous declarative debuggers do not do enough to make the questions easier for the user to answer. The declarative nature of Mercury makes it relatively easy to implement a declarative debugger that can handle the full language. The version of the Mercury declarative debugger that was the starting point for this thesis already handled almost all of Mercury. By extending it to handle exceptions we made it handle the full language

We have implemented a declarative debugger for Mercury that is capable of finding bugs in large, long-running programs. This debugger implements several search strategies. We discuss the implementation of two of these strategies and the conditions under which each strategy is useful. The divide and query strategy tries to minimize the number of questions asked of the user. While divide and query can reduce the number of questions to roughly logarithmic in the size of the computation, implementing it presents practical difficulties for computations whose representations do not fit into memory. We discuss how we get around this problem, making divide and query practical. Our declarative debugger allows users to specify exactly which part of an atom is wrong. The subterm dependency tracking strategy exploits this extra information to jump directly to the part of the program that computed the wrong subterm. In many cases, only a few such jumps are required to arrive at the bug. Subterm dependency tracking can converge on the bug even more quickly than divide and query, and it tends to yield question sequences that are easier for users to answer.

For safety-critical reactive systems (in avionics, transportation, nuclear plants, etc.), a lot of effort has been put on the definition of safe languages, with a formal semantics. In the synchronous approach, several languages with distinct programming styles share a common simple view of the world that helps reasoning about programs formally: systems react in zero time. Formal verification and testing tools have been developed, based upon the formal semantics. But there are very few attempts at providing the user with a tool like a debugger. Simulators exist, but they are restricted to the observation of the global inputs and outputs of the reactive system, and to commands like step (on the base clock, for time-triggered implementations) and reset. We would like to provide a real debugger for reactive systems, in the synchronous approach. We are mainly interested in the data-flow language Lustre, for which the distance between the structure of programs and the actual execu...

Abstract not found