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.

. Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. This should be reflected in the design of debuggers for such languages to avoid burdening the programmer with operational details, e.g. concerning the actual evaluation order. Conventional debugging techniques tend to focus too much on operational aspects to be suitable in this context. A record of the execution that only captures the declarative aspects of the execution, leaving out operational details, would be a viable basis for debugging lazy functional programs. Various declarative debugging tools could then be developed on top of such records. In this paper we propose a structure which we call the Evaluation Dependence Tree (EDT) for this purpose, and we describe two different construction methods. Performance problems are discussed along with possible solutions. Keywords: Declarative languages, lazy functional languages,...

We describe extensions to the Excel spreadsheet that integrate userdefined functions into the spreadsheet grid, rather than treating them as a "bolt-on". Our first objective was to bring the benefits of additional programming language features to a system that is often not recognised as a programming language. Second, in a project involving the evolution of a well-established language, compatibility with previous versions is a major issue, and maintaining this compatibility was our second objective. Third and most important, the commercial success of spreadsheets is largely due to the fact that many people find them more usable than programming languages for programming-like tasks. Thus, our third objective (with resulting constraints) was to maintain this usability advantage.

In this paper, we use a logic-based system description for a simple (non-logic) functional language to examine the ways in which a diagnosis system can use its system description to improve debugging performance. The key concept is that the notion of expression replacement, which is the basis for repairing a program, can also serve as a fundamental heuristic for searching the source of an error. We formally define replacements in terms of fault modes, explicitly define a replacement order, and use the replacement heuristic for finding diagnoses. Finally, we incorporate the use of multiple test cases and discuss their use in discriminating between diagnoses. 1 Introduction Although model-based diagnosis (MBD) [Reiter, 1987; de Kleer and Williams, 1987] provides a general diagnosis framework, most of its applications are within the hardware domain or use models of the physical world. However, several attempts have been made to extend the application of diagnosis methods to software debu...

Declarative (or algorithmic) debugging is a promising technique for debugging lazy functional programs. This paper addresses two important reasons why it is not more widespread: the difficulty of writing a declarative debugger for a lazy functional language in the language itself and the efficiency of the debugger. Using the source language to implement the debugger is desirable for portability and we discuss the reasons why this is very difficult to do. We propose a system in which nearly all the code is in the source language but there is one function which must be written at lower level. We also show how this function can be the key to significantly improving the efficiency of declarative debuggers for such languages. Keywords: algorithmic debugging, referential transparency, i/o, monads, types, trace, transformation 1 Introduction Traditional debugging methods such as diagnostic writes, tracing, break points et cetera are very difficult to apply to modern lazy functional progra...

The type systems of most typed functional programming languages are based on the Hindley-Milner type system. A practical problem with these type systems is that it is often hard to understand why a program is not type correct or a function does not have the intended type. We suggest that at the core of this problem is the difficulty of explaining why a given expression has a certain type. The type system is not defined compositionally. We propose to explain types using a variant of the Hindley-Milner type system that defines a compositional type explanation graph of principal typings. We describe how the programmer understands types by interactive navigation through the explanation graph. Furthermore, the explanation graph can be the foundation for algorithmic debugging of type errors, that is, semi-automatic localisation of the source of a type error without even having to understand the type inference steps. We implemented a prototype of a tool to explore the usefulness of the proposed methods.

In this paper we discuss the relationship between program mutation and model-based diagnosis applied to locate and fix bugs in programs. We show that the time required to search for single faults is smaller in model-based diagnosis than in general program mutation. We use this result to speed up program mutation for debugging and develop a procedure that combines both approaches. Moreover, we show that a suitable model can deliver results that are as expressive as the results obtained by program mutation. This is done by introducing a fault mode REPL for components associated with statements and expressions.

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.