Formally based profiling for higher-order functional languages
ACM Transactions on Programming Languages and Systems (TOPLAS)
The nofib Benchmark Suite of Haskell Programs
Proceedings of the 1992 Glasgow Workshop on Functional Programming
System F with type equality coercions
TLDI '07 Proceedings of the 2007 ACM SIGPLAN international workshop on Types in languages design and implementation
Haskell '07 Proceedings of the ACM SIGPLAN workshop on Haskell workshop
A lightweight interactive debugger for haskell
Haskell '07 Proceedings of the ACM SIGPLAN workshop on Haskell workshop
Proceedings of the 15th ACM SIGPLAN international conference on Functional programming
High coverage testing of Haskell programs
Proceedings of the 2011 International Symposium on Software Testing and Analysis
From stack traces to lazy rewriting sequences
IFL'11 Proceedings of the 23rd international conference on Implementation and Application of Functional Languages
| Hi-index | 0.01 |
Even Haskell programs can occasionally go wrong. Programs calling head on an empty list, and incomplete patterns in function definitions can cause program crashes, reporting little more than the precise location where error was ultimately called. Being told that one application of the head function in your program went wrong, without knowing which use of head went wrong can be infuriating. We present our work on adding the ability to get stack traces out of GHC, for example that our crashing head was used during the evaluation of foo, which was called during the evaluation of bar, during the evaluation of main. We provide a transformation that converts GHC Core programs into ones that pass a stack around, and a stack library that ensures bounded heap usage despite the highly recursive nature of Haskell. We call our extension to GHC StackTrace.