Lazy call-by-value evaluation

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.

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.

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.

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.

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.

Higher-Order and Symbolic Computation, 2008

Tracing computations is a widely used methodology for program debugging. Lazy languages, however, pose new demands on tracing techniques because following the actual trace of a computation is generally useless. Typically, tracers for lazy languages rely on the construction of a redex trail, a graph that stores the reductions performed in a computation. While tracing provides a significant help for locating bugs, the task still remains complex. A well-known debugging technique for imperative programs is based on dynamic slicing, a method for finding the program statements that influence the computation of a value for a specific program input.

Implementation of Functional Languages, 1997

At the High Performance Functional Computing conference in Denver [MoJ95] a new approach to profiling was presented, this allowed the complete set of program costs to be recorded in so-called cost centre stacks. It was proposed that these program costs could then be manipulated using a post-processor which would speed up the task of profiling a Haskell program and would also produce more accurate profiling results.

2006

Lazy programming languages have a very different execution order of expressions which makes debugging such programs a very different experience from debugging eager or imperative programs. We describe a simple idea of how to apply conventional eager language debugging concepts to lazy programming language Haskell. We give a detailed description of how such debugger could be implemented and describe our prototype of this system. Further, we elaborate on how such debugger could be implemented in an efficient way and describe some Haskell runtime extensions that would help this process.

This paper describes a new approach for debugging lazy functional lan- guages. It rests on the fact that a functional program is the transformation of an ex- pression; one debugs a program by investigating the syntactic form of the expression and by stopping the reduction process at given points. We show what problems are involved and our approach to solving them in a prototype implementation.

ACM SIGPLAN Notices, 2004

This paper describes the principles underlying an efficient implementation of a lazy functional language, compiling to code for ordinary computers. It is based on combinator-like graph reduction: the user defined functions are used as rewrite rules in the graph. Each function is compiled into an instruction sequence for an abstract graph reduction machine, called the G-machine, the code reduces a function application graph to its value. The G-machine instructions are then translated into target code. Speed improvements by almost two orders of magnitude over previous lazy evaluators have been measured; we provide some performance figures.