Program execution monitoring consists of checking whole executions for given properties in order to collect global run-time information. Monitoring is very useful to maintain programs. However, application developers face the following dilemma: either they use existing tools which never exactly #t their needs, or they invest a lot of e#ort to implement monitoring code. In this report we argue that, when an event-oriented tracer exists, the compiler developers can enable the application developers to easily code their own, relevant, monitors. We propose a high-level operator, called foldt, which operates on execution traces. One of the key advantages of our approachisthat it allows a clean separation of concerns; the de#nition of monitors is totally distinct from both the user source code and the language compiler. We giveanumber of applications of the foldt operator to compute monitors for Mercury program executions: execution pro#les, graphical abstract views, and two test coverage measurements. Each example is implemented by a few simple lines of Mercury.

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.

This paper describes the design and construction of a Haskell source-level debugger built into the GHCi interactive environment. We have taken a pragmatic approach: the debugger is based on the traditional stop-examine-continue model of online debugging, which is simple and intuitive, but has traditionally been shunned in the context of Haskell because it exposes the lazy evaluation order. We argue that this drawback is not as severe as it may seem, and in some cases is an advantage. The design focusses on availability: our debugger is intended to work on all programs that can be compiled with GHC, and without requiring the programmer to jump through additional hoops to debug their program. The debugger has a novel approach for reconstructing the type of runtime values in a polymorphic context. Our implementation is light on complexity, and was integrated into GHC without significant upheaval. 1.

A program execution monitor is a program that collects and abstracts information about program executions. The collect operator is a high level, general purpose primitive which lets users implement their own monitors. Collect is built on top of the Mercury trace. In previous work, we have demonstrated how this operator can be used to efficiently collect various kinds of statistics about Mercury program executions. In this article we further demonstrate the expressive power and effectiveness of collect by providing more monitor examples. In particular, we show how to implement monitors that generate graphical abstractions of program executions such as proof trees, control flow graphs and dynamic call graphs. We show how those abstractions can be easily modified and adapted, since those monitors only require several dozens of lines of code. Those abstractions are intended to serve as front-ends of software visualization tools. Although collect is currently implemented on top of the Mercury trace, none of its underlying concepts depend of Mercury and it can be implemented on top of any tracer for any programming language.