Abstract. Programmers rely on the correctness of the tools in their programming environments. In the past, semanticists have studied the correctness of compilers and compiler analyses, which are the most important tools. In this paper, we make the case that other tools, such as debuggers and steppers, deserve semantic models, too, and that using these models can help in developing these tools. Our concrete starting point is the algebraic stepper in DrScheme, our Scheme programming environment. The algebraic stepper explains a Scheme computation in terms of an algebraic rewriting of the program text. A program is rewritten until it is in a canonical form (if it has one). The canonical form is the final result. The stepper operates within the existing evaluator, by placing breakpoints and by reconstructing source expressions from source information placed on the stack. This approach raises two questions. First, do the run-time breakpoints correspond to the steps of the reduction semantics? Second, does the debugging mechanism insert enough information to reconstruct source expressions? To answer these questions, we develop a high-level semantic model of the extended compiler and run-time machinery. Rather than modeling the evaluation as a low-level machine, we model the relevant low-level features of the stepper’s implementation in a high-level reduction semantics. We expect the approach to apply to other semantics-based tools. 1 The Correctness of Programming Environment Tools Programming environments provide many tools that process programs semantically. The most common ones are compilers, program analysis tools, debuggers, and profilers. Our DrScheme programming environment [9,8] also provides an algebraic stepper for Scheme. It explains a program’s execution as a sequence of reduction steps based on the ordinary laws of algebra for the functional core [2,

. 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,...

Abstract A side effect is any change in program state that occurs as a by-product of the evaluation of an expression. Side effects are often thought to impede program comprehension and to lead to complex, poorly understood and occasionally undefined semantics. Side-Effect Removal Transformation (SERT) improves comprehension by rewriting a program p which may contain side effects into a semantically equivalent program p0 which is guaranteed to be side-effect free. This paper introduces the SERT approach to the side-effect problem, briefly reporting initial experience with an implementation of SERT for C programs called Linsert1. 1

Due to their reliance on the execution order of programs, traditional debugging techniques are not well suited to locating the source of logical errors in programs written in lazy functional languages. We describe the implementation of a declarative debugger for the programming language Haskell, which assists the location of logical errors based on the declarative semantics of program definitions. The implementation is based on the Hugs interpreter, and both solidifies previous work in the field and extends it to incorporate features typical of many modern lazy functional languages. Contents 1 Introduction 1 2 Haskell 2 2.1 Background : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 2.2 Haskell is a lazy language : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 2.3 Haskell is a higher--order language : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2.4 Haskell is purely functional : : : : : : : : : : :...

. Debugging programs written in lazy functional languages is difficult, and there are currently no realistic, general purpose debugging tools available. The basic problem is that computations in general do not take place in the order one might expect. Furthermore, lazy functional languages are `declarative'. Hence it is advantageous if debugging takes place at the same, high level of abstraction. Thus, we propose to base debugging on what we call Evaluation Dependence Trees (EDT), which reflect the declarative semantics of the programs rather than operational concerns such as evaluation order. This in turn naturally suggests a two level debugger architecture where the lower level generates the EDT and the upper level allows the user to investigate it. The main advantage of this is flexibility: components realizing the two levels may be chosen independently to suit the debugging problem at hand. 1 Introduction For various reasons, as will be explained in the following, debugging progra...

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, and some performance figures from experiments in a realistic c...

Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

We describe a debugger for the lazy functional language Haskell [Hud92]. The idea is to transform a program with a source-to-source transformation to a program that creates an evaluation history when executed. If an error is detected while running the program, the programmer can navigate through the evaluation history, by pointing and clicking in a graphical user interface, to try to find the erroneous definition. The method is compared to other ways of debugging lazy functional programs. Some ideas of improvements are also presented. 1 Introduction If lazy functional languages are ever to be used by more people than computer scientists, the programming environments for these languages must be comparable to (or better than) the environments that are available for more traditional programming languages. A debugger is an important part of a programming environment. It has been argued that there is no need for a debugger for a language with strict static type-checking [HO88, TR86]. This ...

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.

In circumstances when a variable in a program has an incorrect value the process of debugging it is often a process about discovering the history of that variable, or rather the ancestry of the value that it contains. In this paper we propose a new technique for debugging that revolves around being able to trace back through the history of a particular variable or variables that it depends upon. Our development is in the domain of functional programming as the proposal has particular significance in this domain due to the fact that so many standard debugging techniques cannot be used at all.