Transforming Haskell for Tracing

Chitil, Olaf; Runciman, Colin; Wallace, Malcolm

doi:10.1007/3-540-44854-3_11

Cited by 16 publications

(27 citation statements)

References 6 publications

(6 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The tracing of lazy functional languages has received a reasonable amount of attention in the literature (Watson 1997;Gibbons and Wansbrough 1996;Goldson 1994), but none of these systems have progressed to usable tools, except for Hat (Chitil et al 2002), which is currently the most substantial debugging tool available for Haskell. Like Buddha, Hat is based on a program transformation.…”

Section: Program Tracers and Declarative Debuggingmentioning

confidence: 99%

“…A large amount of research, including several PhDs, has gone into debugging functional languages in general and Haskell in particular (Nilsson 1998;Sparud 1999;Pope 2006;Ennals and Peyton Jones 2003a). The most prominent working debuggers for Haskell are Hat (Chitil et al 2002) and Hood (Gill 2000). Hat is a sophisticated system, with a suite of powerful tools, based on solid research.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A lightweight interactive debugger for haskell

Marlow

Iborra

Pope

et al. 2007

Proceedings of the ACM SIGPLAN Workshop on Haskell Workshop

View full text Add to dashboard Cite

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

show abstract

Section: Program Tracers and Declarative Debuggingmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

A lightweight interactive debugger for haskell

Marlow

Iborra

Pope

et al. 2007

Proceedings of the ACM SIGPLAN Workshop on Haskell Workshop

View full text Add to dashboard Cite

show abstract

“…The expected result of the program is the ordered list [3,4,5], but when executed the program prints [3,5,4] instead. The program uses many standard library functions such as ++ and foldr that are trusted, that is, assumed to be correct.…”

Section: Background Observation and Ideamentioning

confidence: 99%

Algorithmic debugging of real-world haskell programs: deriving dependencies from the cost centre stack

Faddegon

Chitil

2015

Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation

Self Cite

View full text Add to dashboard Cite

Existing algorithmic debuggers for Haskell require a transformation of all modules in a program, even libraries that the user does not want to debug and which may use language features not supported by the debugger. This is a pity, because a promising approach to debugging is therefore not applicable to many real-world programs. We use the cost centre stack from the Glasgow Haskell Compiler profiling environment together with runtime value observations as provided by the Haskell Object Observation Debugger (HOOD) to collect enough information for algorithmic debugging. Program annotations are in suspected modules only. With this technique algorithmic debugging is applicable to a much larger set of Haskell programs. This demonstrates that for functional languages in general a simple stack trace extension is useful to support tasks such as profiling and debugging.

show abstract

“…where the counter model can be reconstructed by taking [2] for xs (the first argument of the property), and [-2,1] for ys (the second argument). We will later see how we can use tracing to see what actually happens with the functions in a property when running it on a failing test case.…”

Section: Defining Propertiesmentioning

confidence: 99%

“…In these lecture notes we concentrate on QuickCheck [3,4], a tool for testing Haskell programs, and Hat [15,2], a tool for tracing them. Each tool is useful in its own right but, as we shall see, they are even more useful in combination: testing using QuickCheck can identify failing cases, tracing using Hat can reveal the causes of failure.…”

Section: Introductionmentioning

confidence: 99%