J.T. O'Donnell and C.V. Hall. Debugging in applicative languages. Journal of LISP and Symbolic Computation, 29(1):113--145, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....variable watching. These difficulties are not serious in the case of eager functional programming, where the evaluation order is easy to predict. In the field of lazy functional programming, the problem is well known since the mid eighties. Most work in this area, starting with early proposals as [16], suggests to generate some form of execution record as a basis for debugging. In the field of logic programming, E.Y. Shapiro [19] proposed declarative debugging (also called algorithmic debugging) a semiautomatic technique which allows to detect bugs on the basis of the intended meaning of the ....

J.T. O'Donnell and C.V. Hall. Debugging in applicative languages. Journal of LISP and Symbolic Computation, 29(1):113--145, 1988.

....to learn and debug. While the conciseness, strong typing and expressiveness of these languages eases program development and reduces the probability of program errors, debugging an erroneous program can be difficult, a problem recognised early in the development of lazy functional languages [18, 15]. For instance, side effects are prohibited in a pure language so adding debugging statements, a typical imperative language approach, is not possible. Debugging at the underlying evaluation machine level [24, 20] is also difficult as the structures encountered there are often unrelated to the ....

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, Volume 1, Number 2, pages 113--145, 1988.

....a tracer for pure lambda calculus (with no primitives) allowing call by name and a kind of lazy evaluation ( call by name with some sharing ) However, this system performs computation under lambda abstractions, so does not model lazy evaluation as in most functional languages. Several authors [17, 21, 16, 26] describe a transformational approach to tracing, whereby the program to be traced is transformed to return a pair consisting of the original result and some trace information . However, this approach comes adrift because of lazy evaluation; the trace information usually concerns partially ....

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, Volume 1, pages 113-- 145, 1988.

.... ones, such as Haskell [4] They are characterized by demand driven evaluation: no expression is evaluated unless its result is needed to compute part of the output, and then it is evaluated at most once (hence lazy) Lazy debugging is difficult for precisely the reasons discussed above [11], and there are currently no realistic, general purpose debuggers available for this type of language. This confines lazy functional programmers to basic debugging techniques, such as bottom up testing of individual functions. Due to the high level nature of lazy functional languages, and the ....

....error to the construct in the source code that causes it. 8 NILSSON AND SPARUD 4. The Evaluation Dependence Tree The insight that lazy functional languages require special tools and techniques for debugging is not new. Some of the earliest work in the area known to us is Hall O Donnell [2] [11], where they identify the difficult to predict evaluation order as a key problem of debugging lazy functional programs using conventional techniques, and propose a number of possible solutions. A review of related work can be found in section 7, but it is interesting to note here that most work in ....

[Article contains additional citation context not shown here]

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1(2):113--145, 1988.

....concerns debugging, thus motivating the work presented in this thesis. Moreover, to spread the use of lazy functional languages more widely, suitable debugging tools will be necessary. The lack of debugging tools has been apparent for quite some time, and, as has been pointed out earlier by others [HO85, OH88, Toy87], it is clear that traditional debugging techniques (e.g. breakpoints, tracing, variable watching etc. in the conventional sense) are not particularly well suited in this context because computations in a lazy program, due to the demand driven execution model, generally do not take place in the ....

....3.2 Related Work In this section, some proposed debugging approaches for lazy languages are reviewed. This is by no means neither an exhaustive survey, nor a very deep and detailed one, but it probably covers the most important ideas in the field. 3.2. 1 Hall O Donnell Hall O Donnell [HO85, OH88] propose a number of approaches to debugging for lazy functional languages in two articles. Their focus is on implementing debugging tools within an interactive, purely functional environment, the main argument for this being portability. They use the language Daisy, a lazy descendant of Lisp. ....

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1(2):113--145, 1988.

....Errors in the design and implementation of an algorithm. These may be detected, for example, by checking assertions about the relationship of a function s arguments to its result. Applying a suspect function to a range of arguments is a technique used by several of the researchers mentioned below [54, 64]. Errors in performance of a program. That is: errors in the speed at which a program runs, and errors in the amount of memory used. These two aspects of performance appear to be closely related a lazy functional program that is doctored to make use of less space will usually run faster [75] ....

....or propagate an exception is given an exception continuation as an extra argument. This will be applied to any exception that arises to produce the result. He gives as an example a putative exception generated by arithmetic overflow. This, however, is a reminder of a comment by Hall and O Donnell [64] that error values tend to be oriented towards handling exceptional numeric conditions and are less useful in other circumstances. 4.3.3 Instrumentation of the SML NJ compiler Tolmach and Appel [87] describe a system that uses automatic instrumentation of the user s code. They note that ....

[Article contains additional citation context not shown here]

J. T. O'Donnell and C. V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1:113--145, 1988.

....(Actually we generate a pair the result of the original program together with its evaluation trace. While others have described how a trace of reductions can be generated (see e.g. Snyder, 1990; Goldson, 1994) and how a transformed (instrumented) program can be used to produce a trace (O Donnell and Hall, 1988; Kishon, 1992; Sparud, 1996) our work is unique in that we combine these two features together with a formal semantic model of lazy evaluation which serves to define the reduction steps that the trace reports. Our transform system, for which we provide a set of simple rules, uniformly handles ....

....a trace (Snyder, 1990; Nilsson and Fritzson, 1994) 2. build a special purpose interpreter which reports its evaluation steps (Goldson, 1994; Augustson, 1995; Gibbons and Wansbrough 1996) 3. transform the original program so that evaluation of the instrumented program generates a trace (O Donnell and Hall, 1988; Sparud, 1996; Naish and Barbour 1996) While all these schemes have their merits, we have chosen to employ the program instrumentation approach. This yields a portable scheme, applicable to different languages and implementations. The program instrumentation aims to simulate an evaluation ....

J. T. O'Donnell and C. V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1(2):113--145, 1988.

.... ones, such as Haskell [4] They are characterized by demand driven evaluation: no expression is evaluated unless its result is needed to compute part of the output, and then it is evaluated at most once (hence lazy) Lazy debugging is difficult for precisely the reasons discussed above [10], and there are currently no realistic, general purpose debuggers available for this type of language. This confines lazy functional programmers to basic debugging techniques, such as bottom up testing of individual functions, or, if available, tracing at the operational level. Due to the ....

....to relate an execution error to the construct in the source code that causes it. 3 The Evaluation Dependence Tree The insight that lazy functional languages require special tools and techniques for debugging is not new. Some of the earliest work in the area known to us is Hall O Donnell [2, 10], where they identify the difficult to predict evaluation order as a key problem of debugging lazy functional programs using conventional techniques, and propose a number of possible solutions. A review of related work can be found in section 6, but it is interesting to note here that most work in ....

[Article contains additional citation context not shown here]

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1(2):113--145, 1988.

....it is imperative that something is done about it, if lazy functional languages are to gain popularity and credibility on a larger scale outside a dedicated scientific community. The lack of debugging tools has been apparent for quite some time, and, as has been pointed out earlier by others [HO85, OH88, Toy87] it is clear that traditional debugging techniques (e.g. breakpoints, tracing, variable watching etc. in the conventional sense) are not particularly well suited in this context because computations in a lazy program, due to the demand driven execution model, generally do not take place ....

....that causes it than what is the case in more traditional languages with call by value semantics. 2.3 Related Work The insight that lazy functional languages require special tools and techniques for debugging is not new. Some of the earliest work in the area known to us is Hall O Donnell [HO85, OH88] In their articles they focus on implementing debugging tools within an interactive, purely functional environment, the main argument for this being portability. One approach that they suggest is to transform the source code of the entire program so that, in addition to its normal value, the ....

John T. O'Donnell and Cordelia V. Hall. Debugging in applicative languages. Lisp and Symbolic Computation, 1(2):113--145, 1988.

....called interpreters , play a variety of roles in the study of programming languages. They define the meaning of programs [7] support the development of new language paradigms [3] relate abstract semantics of programs to the corresponding concrete semantics [2] provide debugging information [5], and yet are simple enough to teach students about the implementation of programming languages. Given this, it s surprising that we don t have a better framework for developing evaluators and specifying their relationship to each other. For example, at least two new innovations in the ....

O'Donnell, J.T. and C.V. Hall, Debugging in applicative languages, Lisp and Symbolic Computation, 1, 113-145 (1988). 13

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC