Results 1 - 10
of
14
Declarative debugging for lazy functional languages
, 1998
"... Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. It is desirable to maintain a declarative view also during debugging so as to avoid burdening the programmer with operational details, for e ..."
Abstract
-
Cited by 77 (8 self)
- Add to MetaCart
Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. It is desirable to maintain a declarative view also during debugging so as to avoid burdening the programmer with operational details, for example concerning the actual evaluation order which tends to be difficult to follow. Conventional debugging techniques focus on the operational behaviour of a program and thus do not constitute a suitable foundation for a general-purpose debugger for lazy functional languages. Yet, the only readily available, general-purpose debugging tools for this class of languages are simple, operational tracers. This thesis presents a technique for debugging lazy functional programs declaratively and an efficient implementation of a declarative debugger for a large subset of Haskell. As far as we know, this is the first implementation of such a debugger which is sufficiently efficient to be useful in practice. Our approach is to construct a declarative trace which hides the operational details,
A rational deconstruction of Landin’s SECD machine
- Implementation and Application of Functional Languages, 16th International Workshop, IFL’04, number 3474 in Lecture Notes in Computer Science
, 2004
"... Abstract. Landin’s SECD machine was the first abstract machine for applicative expressions, i.e., functional programs. Landin’s J operator was the first control operator for functional languages, and was specified by an extension of the SECD machine. We present a family of evaluation functions corre ..."
Abstract
-
Cited by 23 (16 self)
- Add to MetaCart
Abstract. Landin’s SECD machine was the first abstract machine for applicative expressions, i.e., functional programs. Landin’s J operator was the first control operator for functional languages, and was specified by an extension of the SECD machine. We present a family of evaluation functions corresponding to this extension of the SECD machine, using a series of elementary transformations (transformation into continuation-passing style (CPS) and defunctionalization, chiefly) and their left inverses (transformation into direct style and refunctionalization). To this end, we modernize the SECD machine into a bisimilar one that operates in lockstep with the original one but that (1) does not use a data stack and (2) uses the caller-save rather than the callee-save convention for environments. We also identify that the dump component of the SECD machine is managed in a callee-save way. The caller-save counterpart of the modernized SECD machine precisely corresponds to Thielecke’s doublebarrelled continuations and to Felleisen’s encoding of J in terms of call/cc. We then variously characterize the J operator in terms of CPS and in terms of delimited-control operators in the CPS hierarchy. As a byproduct, we also present several reduction semantics for applicative expressions
A Transformational Approach to Debugging Lazy Functional Programs
, 1996
"... We describe a debugger for the lazy functional language Haskell. The basic idea is to transform a Haskell program into a program that evaluates to the same result as the original program but also produces an evaluation dependence tree describing how the result was obtained. If an error is detected w ..."
Abstract
-
Cited by 10 (3 self)
- Add to MetaCart
We describe a debugger for the lazy functional language Haskell. The basic idea is to transform a Haskell program into a program that evaluates to the same result as the original program but also produces an evaluation dependence tree describing how the result was obtained. If an error is detected while running the program, the programmer can browse the evaluation dependence tree, or use algorithmic debugging, in order to try to find the erroneous definition. The method is compared to other ways of debugging lazy functional programs. Some ideas for improvements are also presented.
A Declarative Approach to Debugging for Lazy Functional Languages
, 1994
"... Machine (FAM), which can be considered as an optimized SECD machine, has been constructed [Car84]. However, the environment based scheme seems to be best suited for languages with strict semantics [FH88, p. 241]. Also, it is probably not so suitable for parallel implementation of lazy functional lan ..."
Abstract
-
Cited by 8 (4 self)
- Add to MetaCart
Machine (FAM), which can be considered as an optimized SECD machine, has been constructed [Car84]. However, the environment based scheme seems to be best suited for languages with strict semantics [FH88, p. 241]. Also, it is probably not so suitable for parallel implementation of lazy functional languages [PJ87, pp. 379, 409--430]. The second approach to lambda calculus implementation, graph reduction, appears to be better suited both for implementation of languages with non-strict semantics and for parallel implementations. The G-machine is based on graph reduction, and since the G-machine was chosen as a basis for the Freja implementation, we will not consider environment based implementations further. 2.3.5 Graph Reduction Graph reduction is a much newer technique than the environment based scheme and was first invented by Wadsworth [Wad71]. The basic idea is to represent lambda expressions as graphs, since graphs are much more convenient for computers to manipulate than text, and...
The Evaluation Dependence Tree: An Execution Record for Lazy Functional Debugging
, 1996
"... 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. concer ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
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...
Towards a Haskell Debugger
, 1995
"... We describe a debugger for the lazy functional language Haskell [Hud92]. The basic idea is to transform a Haskell program into a program that evaluates to the same result as the original program but also produces an evaluation dependence tree describing how the result was obtained. If an error is de ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
We describe a debugger for the lazy functional language Haskell [Hud92]. The basic idea is to transform a Haskell program into a program that evaluates to the same result as the original program but also produces an evaluation dependence tree describing how the result was obtained. If an error is detected while running the program, the programmer can navigate through the evaluation dependence tree, 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 ...
A Visual Programming Environment for Functional Languages
, 2002
"... I declare that this thesis is my own account of my research and contains as its main content work which has not previously been submitted for a degree at any tertiary education institution. Joel Kelso ii The purported advantages of Visual Programming, as applied to general purpose programming langua ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
I declare that this thesis is my own account of my research and contains as its main content work which has not previously been submitted for a degree at any tertiary education institution. Joel Kelso ii The purported advantages of Visual Programming, as applied to general purpose programming languages, have remained largely unfulfilled. The essence of this thesis is that functional programming languages have at least one natural visual representation, and that a useful programming environment can be based upon this representation. This thesis describes the implementation of a Visual Functional Programming Environment (VFPE). The programming environment has several significant features. • The environment includes a program editor that is inherently
Graphical application and visualization of lazy functional computation
, 1995
"... 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. ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
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
A Trace Browser for a Lazy Functional Language
- In Proceedings of the Twentieth Australian Computer Science Conference
, 1997
"... This paper describes how to construct a tool that enables a programmer to view the evaluation behaviour of a lazy functional program. In the system presented, the program is first transformed so that on execution it produces a trace of expression evaluation, and this trace is passed to a browser whi ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
This paper describes how to construct a tool that enables a programmer to view the evaluation behaviour of a lazy functional program. In the system presented, the program is first transformed so that on execution it produces a trace of expression evaluation, and this trace is passed to a browser which provides facilities for the user to navigate over the trace. We concentrate on issues around browser design, namely the identification of suitable functionality for effective navigation, and a suitable architecture for its construction. A prototype browser is presented. Keywords Lazy functional languages, debugging. 1 Introduction Over the last decade or so lazy functional languages have become increasingly popular [7, 9], with modern languages such as Miranda 1 [25] and Haskell [8] being adopted as vehicles for teaching programming and formal reasoning techniques to computer science students [23]. Despite their growing popularity, programmers can find lazy functional languages challe...

