WinHIPE

Pareja-Flores, Cristóbal; Urquiza-Fuentes, Jamie; Velázquez‐Iturbide, J. Ángel

doi:10.1145/1273039.1273042

Cited by 22 publications

(3 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In the program trace we have already exhibited, it is clear that for realistic programs, the program trace (both its width and its length) may be significant. This issue is discussed in some detail by Taylor [41] and Pajera-Flores [30]. A practical solution, we claim, must involve providing ways of a) eliding information within a single step -reducing the width; b) eliding whole steps -reducing the length; c) searching the resultant trace, if it is still too large to spot the bug; and d) moving backward and forward through the trace to connect cause and effect in the computation.…”

Section: An Examplementioning

confidence: 99%

See 1 more Smart Citation

Direct Interpretation of Functional Programs for Debugging

Whitington

Ridge

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

We make another assault on the longstanding problem of debugging. After exploring why debuggers are not used as widely as one might expect, especially in functional programming environments, we define the characteristics of a debugger which make it usable and thus widely used. We present initial work towards a new debugger for OCaml which operates by direct interpretation of the program source, allowing the printing out of individual steps of the program's evaluation. We present OCamli, a standalone interpreter, and propose a mechanism by which the interpreter could be integrated into compiled executables, allowing part of a program to be interpreted in the same fashion as OCamli whilst the rest of the program runs natively. We show how such a mechanism might create a sourcelevel debugging system that has the characteristics of a usable debugger (such as being independent of its environment) and so may eventually be expected to be suitable for widespread adoption. Direct Interpretation of Functional Programs for Debuggingall bugs except those so glaring as to leap to the first fresh eye cast on the program. . . . An unfriendly behaviorist studying programmers might conclude that we deliberately elaborate our tasks so as to keep the bug rate constant." [22]. Balzer, in his 1969 description of the Rand Corporation's EXDAMS debugger [2], explains that this surprise was widespread in the industry, at a time when more and more large programs were being written in modern compiled languages: "With the advent of the higher-level algebraic languages, the computer industry expected to be relieved of the detailed programming required at the assembly-language level. This expectation has largely been realised. Many systems are now being built in higher-level languages (most notably MULTICS). . . . However, the ability to debug programs has advanced but little with the increased use of these high-level languages." [2]. Hamlet, writing in 1983, gives a possible reason -the lack of attendant progress in debugging paradigms, suggesting that high level languages might require different kinds of debugging tools rather than mere analogs of existing ones: "Debugging techniques originated with low-level programming languages, where the memory dump and interactive word-by-word examination of memory were the primary tools. 'High-level' debugging is often no more than low-level techniques adapted to high-level languages." [24]. It is fascinating to see Halpern, quoted earlier, writing on the same topic forty years later, in 2005: "The most remarkable thing about debugging today is how little it differs from debugging at the dawn of modern computing age, half a century ago. . . . We've made little progress in debugging methods in half a century, with the result that projects everywhere are bogged down because of buggy software." [23] Debuggers are still not as widely used as one might expect, even in difficult domains. In a paper on debugging practices for complex legacy systems, Regelson and Anderson write: "The major item noted by surve...

show abstract

Section: An Examplementioning

confidence: 99%

“…The WinHIPE system [30] is a recent incarnation of these ideas for the HOPE [4] language. It uses a stepby-step evaluation system, and explicitly addresses the problems of scale by elision of information and a focusing mechanism.…”

Section: Functional Program Visualizationmentioning

confidence: 99%

Direct Interpretation of Functional Programs for Debugging

Whitington

Ridge

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

show abstract

“…A disadvantage of this method is that the instrumentation of the original code can alter the execution of the program. The second method, which is used for example by WinHIPE [24], is to instrument the interpreter. The advantage of this method is that the execution of the program is exactly the same, but a disadvantage is that the interpreter (part of the compiler) needs to be adjusted.…”

Section: Related Workmentioning

confidence: 99%

Evaluating Haskell expressions in a tutoring environment

Olmer

Heeren

Jeuring

2014

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

A number of introductory textbooks for Haskell use calculations right from the start to give the reader insight into the evaluation of expressions and the behavior of functional programs. Many programming concepts that are important in the functional programming paradigm, such as recursion, higher-order functions, pattern-matching, and lazy evaluation, can be partially explained by showing a stepwise computation. A student gets a better understanding of these concepts if she performs these evaluation steps herself. Tool support for experimenting with the evaluation of Haskell expressions is currently lacking. In this paper we present a prototype implementation of a stepwise evaluator for Haskell expressions that supports multiple evaluation strategies, specifically targeted at education. Besides performing evaluation steps the tool also diagnoses steps that are submitted by a student, and provides feedback. Instructors can add or change function definitions without knowledge of the tool's internal implementation. We discuss some preliminary results of a small survey about the tool.

show abstract