1,313 research outputs found
Compositional Explanation of Types and Algorithmic Debugging of Type Errors
The type systems of most typed functional programming languages are based on the Hindley-Milner type system. A practical problem with these type systems is that it is often hard to understand why a program is not type correct or a function does not have the intended type. We suggest that at the core of this problem is the difficulty of explaining why a given expression has a certain type. The type system is not defined compositionally. We propose to explain types using a variant of the Hindley-Milner type system that defines a compositional type explanation graph of principal typings. We describe how the programmer understands types by interactive navigation through the explanation graph. Furthermore, the explanation graph can be the foundation for algorithmic debugging of type errors, that is, semi-automatic localisation of the source of a type error without even having to understand the type inference steps. We implemented a prototype of a tool to explore the usefulness of the proposed methods
Report on a User Test and Extension of a Type Debugger for Novice Programmers
A type debugger interactively detects the expressions that cause type errors.
It asks users whether they intend the types of identifiers to be those that the
compiler inferred. However, it seems that novice programmers often get in
trouble when they think about how to fix type errors by reading the messages
given by the type debugger. In this paper, we analyze the user tests of a type
debugger and report problems of the current type debugger. We then extend the
type debugger to address these problems. Specifically, we introduce
expression-specific error messages and language levels. Finally, we show type
errors that we think are difficult to explain to novice programmers. The
subjects of the user tests were 40 novice students belonging to the department
of information science at Ochanomizu University.Comment: In Proceedings TFPIE 2014, arXiv:1412.473
Algorithmic Debugging of Real-World Haskell Programs: Deriving Dependencies from the Cost Centre Stack
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 ap- proach 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
Finding The Lazy Programmer's Bugs
Traditionally developers and testers created huge numbers of explicit tests, enumerating interesting cases, perhaps
biased by what they believe to be the current boundary conditions of the function being tested. Or at
least, they were supposed to.
A major step forward was the development of property testing. Property testing requires the user to write a few
functional properties that are used to generate tests, and requires an external library or tool to create test data
for the tests. As such many thousands of tests can be created for a single property. For the purely functional
programming language Haskell there are several such libraries; for example QuickCheck [CH00], SmallCheck
and Lazy SmallCheck [RNL08].
Unfortunately, property testing still requires the user to write explicit tests. Fortunately, we note there are
already many implicit tests present in programs. Developers may throw assertion errors, or the compiler may
silently insert runtime exceptions for incomplete pattern matches.
We attempt to automate the testing process using these implicit tests. Our contributions are in four main
areas: (1) We have developed algorithms to automatically infer appropriate constructors and functions needed
to generate test data without requiring additional programmer work or annotations. (2) To combine the
constructors and functions into test expressions we take advantage of Haskell's lazy evaluation semantics by
applying the techniques of needed narrowing and lazy instantiation to guide generation. (3) We keep the type
of test data at its most general, in order to prevent committing too early to monomorphic types that cause
needless wasted tests. (4) We have developed novel ways of creating Haskell case expressions to inspect elements
inside returned data structures, in order to discover exceptions that may be hidden by laziness, and to make
our test data generation algorithm more expressive.
In order to validate our claims, we have implemented these techniques in Irulan, a fully automatic tool for
generating systematic black-box unit tests for Haskell library code. We have designed Irulan to generate high
coverage test suites and detect common programming errors in the process
Enumerating Counter-Factual Type Error Messages with an Existing Type Checker
The type error message of a standard type checker for a functional language gives only a single location as potential cause of the type error. If that location is not the cause, which often is the case, then the type error message hardly helps in locating the real cause. Here we present a method that uses a standard type checker to enumerate locations that potentially cause the type error, each with an actual and a counter-factual type for the given location. Adding our method to existing compilers requires only limited effort but improves type error debugging substantially
Extending Nunchaku to Dependent Type Theory
Nunchaku is a new higher-order counterexample generator based on a sequence
of transformations from polymorphic higher-order logic to first-order logic.
Unlike its predecessor Nitpick for Isabelle, it is designed as a stand-alone
tool, with frontends for various proof assistants. In this short paper, we
present some ideas to extend Nunchaku with partial support for dependent types
and type classes, to make frontends for Coq and other systems based on
dependent type theory more useful.Comment: In Proceedings HaTT 2016, arXiv:1606.0542
- …