1,869 research outputs found
Idempotent I/O for safe time travel
Debuggers for logic programming languages have traditionally had a capability
most other debuggers did not: the ability to jump back to a previous state of
the program, effectively travelling back in time in the history of the
computation. This ``retry'' capability is very useful, allowing programmers to
examine in detail a part of the computation that they previously stepped over.
Unfortunately, it also creates a problem: while the debugger may be able to
restore the previous values of variables, it cannot restore the part of the
program's state that is affected by I/O operations. If the part of the
computation being jumped back over performs I/O, then the program will perform
these I/O operations twice, which will result in unwanted effects ranging from
the benign (e.g. output appearing twice) to the fatal (e.g. trying to close an
already closed file). We present a simple mechanism for ensuring that every I/O
action called for by the program is executed at most once, even if the
programmer asks the debugger to travel back in time from after the action to
before the action. The overhead of this mechanism is low enough and can be
controlled well enough to make it practical to use it to debug computations
that do significant amounts of I/O.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth
International Workshop on Automated Debugging (AADEBUG 2003), September 2003,
Ghent. cs.SE/030902
A Machine-Independent Debugger--Revisited
Most debuggers are notoriously machine-dependent, but some recent research
prototypes achieve varying degrees of machine-independence with novel designs.
Cdb, a simple source-level debugger for C, is completely independent of its
target architecture. This independence is achieved by embedding symbol tables
and debugging code in the target program, which costs both time and space. This
paper describes a revised design and implementation of cdb that reduces the
space cost by nearly one-half and the time cost by 13% by storing symbol tables
in external files. A symbol table is defined by a 31-line grammar in the
Abstract Syntax Description Language (ASDL). ASDL is a domain-specific language
for specifying tree data structures. The ASDL tools accept an ASDL grammar and
generate code to construct, read, and write these data structures. Using ASDL
automates implementing parts of the debugger, and the grammar documents the
symbol table concisely. Using ASDL also suggested simplifications to the
interface between the debugger and the target program. Perhaps most important,
ASDL emphasizes that symbol tables are data structures, not file formats. Many
of the pitfalls of working with low-level file formats can be avoided by
focusing instead on high-level data structures and automating the
implementation details.Comment: 12 pages; 6 figures; 3 table
Functional programming languages for verification tools: experiences with ML and Haskell
We compare Haskell with ML as programming languages for verification tools, based on our experience developing TRUTH in Haskell and the Edinburgh Concurrency Workbench (CWB) in ML. We discuss not only technical language features but also the "worlds" of the languages, for example, the availability of tools and libraries
Enumerating Counter-Factual Type Error Messages with an Existing Type Checker (poster+demo)
The Hindley-Milner type system is a foundation for most statically typed
functional programming languages, such as ML, OCaml and Haskell. This type
system has many advantageous, but it does make type debugging hard: If a
program is not well-typed, it can be difficult for the programmer to locate the
cause of the type error, that is, to determine where to change the program how.
Many solutions to the problem have been proposed. Here we propose a new
solution with two distinctive advantages: It is easy to use for the functional
programmer, because it appears to be only a minor extension of the type error
messages they are already familiar with. It is easy to implement, because it does
not require the implementation of a new type checker, but instead reuses any
existing one as a subroutine (like [2])
- ā¦