Tracing piece by piece: affordable debugging for lazy functional languages (original) (raw)
Related papers
How to look busy while being as lazy as ever: the Implementation of a lazy functional debugger
Journal of Functional Programming, 2001
This article describes the implementation of a debugger for lazy functional languages like Haskell. The key idea is to construct a declarative trace which hides the operational details of lazy evaluation. However, to avoid excessive memory consumption, the trace is constructed one piece at a time, as needed during a debugging session, by automatic re-execution of the program being debugged. The article gives a fairly detailed account of both the underlying ideas and of our implementation, and also presents performance figures which demonstrate the feasibility of the approach.
Algorithmic debugging for lazy functional languages
Journal of Functional Programming, 1994
Lazy functional languages have non-strict semantics and are purely declarative, i.e. they support the notion of referential transparency and are devoid of side-effects. Traditional debugging techniques are, however, not suited for lazy functional languages since, computations generally do not take place in the order one might expect. Since algorithmic debugging allows the user to concentrate on the declarative aspects of program semantics, and will semi-automatically find functions containing bugs, we propose to use this technique for debugging lazy functional programs. Because of the non-strict semantics of lazy functional languages, arguments to functions are in general partially evaluated expressions. The user is, however, usually more concerned with the values that these expressions represent. We address this problem by providing the user with a strictified view of the execution trace whenever possible. In this paper, we present an algorithmic debugger for a lazy functional language based on strictification and some experience in using it. A number of problems with the current implementation of the debugger (e.g. too large trace size and too many questions asked) are also discussed and some techniques for overcoming these problems, at least partially, are suggested, the key techniques being immediate strictification and piecemeal tracing.
Lazy algorithmic debugging: Ideas for practical implementation
Lecture Notes in Computer Science, 1993
Lazy functional languages have non-strict semantics and are purely declarative, i.e. they support the notion of referential transparency and are devoid of side effects. Traditional debugging techniques are, however, not suited for lazy functional languages since computations generally do not take place in the order one might expect. Since algorithmic debugging allows the user to concentrate on the declarative aspects of program semantics, and will semi-automatically find functions containing bugs, we propose to use this technique for debugging lazy functional programs. Our earlier work showed that this is a promising approach. However, the current version of our debugger has severe implementational problems, e.g. too large trace size and too many questions asked. This paper suggests a number of techniques for overcoming these problems, at least partially.
The evaluation dependence tree as a basis for lazy functional debugging
Automated Software Engineering, 1997
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.
Tracing lazy functional languages
1995
We argue that Ariola and Felleisen's and Maraist, Odersky and Wadler's axiomatization of the call-by-need lambda calculus forms a suitable formal basis for tracing evaluation in lazy functional languages. In particular, it allows a one-dimensional textual representation of terms, rather than requiring a two-dimensional graphical representation using arrows. We describe a program LetTrace, implemented in Gofer and tracing lazy evaluation of a subset of Gofer.
A Technique to Build Debugging Tools for Lazy Functional Logic Languages
Electronic Notes in Theoretical Computer Science, 2009
This paper is based on a recently developed technique to build debugging tools for lazy functional programming languages. With this technique it is possible to replay the execution of a lazy program with a strict semantics by recording information of unevaluated expressions. The recorded information is called an oracle and is very compact. Oracles contain the number of strict steps between discarding unevaluated expressions. The technique has already been successfully employed to construct a debugger for lazy functional languages. This paper extends the technique to include also lazy functional logic languages. A debugging tool built with the technique can be downloaded at www-ps.informatik.uni-kiel.de/~bbr.
Profiling large-scale lazy functional programs
Journal of Functional Programming, 1998
The LOLITA natural language processor is an example of one of the ever-increasing number of large-scale systems written entirely in a functional programming language. The system consists of over 47,000 lines of Haskell code (excluding comments) and is able to perform a wide range of tasks such as semantic and pragmatic analysis of text, information extraction and query analysis. The efficiency of such a system is critical; interactive tasks (such as query analysis) must ensure that the user is not inconvenienced by long pauses, and batch mode tasks (such as information extraction) must ensure that an adequate throughput can be achieved. For the past three years the profiling tools supplied with GHC and HBC have been used to analyse and reason about the complexity of the LOLITA system. There have been good results, however experience has shown that in a large system the profiling life-cycle is often too long to make detailed analysis possible, and the results are often misleading. In response to these problems a profiler has been developed which allows the complete set of program costs to be recorded in so-called cost-centre stacks. These program costs are then analysed using a post-processing tool to allow the developer to explore the costs of the program in ways that are either not possible with existing tools or would require repeated compilations and executions of the program. The modifications to the Glasgow Haskell compiler based on detailed cost semantics and an efficient implementation scheme are discussed. The results of using this new profiling tool in the analysis of a number of Haskell programs are also presented. The overheads of the scheme are discussed and the benefits of this new system are considered. An outline is also given of how this approach can be modified to assist with the tracing and debugging of programs.
A Declarative Debugging System for Lazy Functional Logic Programs
Electronic Notes in Theoretical Computer Science, 2002
We present a declarative debugger for lazy functional logic programs with polymorphic type discipline. Whenever a computed answer is considered wrong by the user (error symptom), the debugger locates a program fragment (function defining rule) responsible for the error. The notions of symptom and error have a declarative meaning w.r.t. to an intended program semantics. Debugging is performed by searching in a computation tree which is a logical representation of the computation. Following a known technique, our tool is based on a program transformation: transformed programs return computation trees along with the results expected by source programs. Our transformation is provably correct w.r.t. well-typing and program semantics. As additional improvements w.r.t. related approaches, we solve a previously open problem concerning the use of curried functions, and we provide a correct method for avoiding redundant questions to the user during debugging. A prototype implementation of the debugger is available. Case studies and extensions are planned as future work.
Sigplan Notices, 2007
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.