Haxl users at Facebook do a lot of development and testing inside GHCi. In fact, we’ve built a customized version of GHCi that runs code in our Haxl monad by default instead of the IO monad, and has a handful of extra commands to support common workflows needed by our developers. This is a pretty smooth setup: right inside GHCi we can test the production code against real data, and interact with all of the services that our production systems talk to, while having a nice interactive edit/compile/test cycle.
However, one thing is missed by many developers, especially those coming from other languages: easy access to a stack trace when debugging.
This talk will tell the story of how we implemented always-on stack traces in GHCi, which are now available in GHC 8.0.1. The implementation involves splitting out the interpreter from GHCi into a separate process, so that the interpreted code can run in profiling mode (where stack traces are available), while the compiler continues to run at full speed on the unprofiled runtime. GHC communicates with the interpreter using binary messages over a pipe.
Remote GHCi has a number of other benefits, including fixing the long-standing annoyance that to compile TH code with -prof you had to build it twice. It will also be useful for using TH when cross-compiling, and has a lot of overlap with a similar mechanism already implemented in GHCJS; indeed we hope to converge on a single implementation in the future.
(more background for the talk in this blog post: http://simonmar.github.io/posts/2016-02-12-Stack-traces-in-GHCi.html)
Simon Marlow is a Software Engineer on Facebook’s Site Integrity Infrastructure team in London. He is working on Haxl, a Haskell-based domain-specific language that is used by the teams fighting spam and malware. Simon is a co-author of the Glasgow Haskell Compiler, author of the book “Parallel and Concurrent Programming in Haskell”, and has a string of research publications in functional programming, language design, compilers, and language implementation.