Shared publicly  - 
 
After bashing my head against this problem on and off for several years, I think I finally understand how to track call stacks properly in a lazy functional language. If this pans out, we'll get backtraces in GHCi and more accurate profiling.
221
24
Andy Gill's profile photoMark Wotton's profile photoDavid Leuschner's profile photoSimon Marlow's profile photo
23 comments
 
Please give here a shout in case you decide to document it in a paper or a blog post.
 
Great news! We're already looking forward to testing the new profiler! :-)
 
So, that would only work in GHCi? Will it have a performance impact?
 
+Thomas Schilling it should also be possible to have a compile-time option to enable stack tracing, but information is lost when interacting with code compiled without stack tracing. It remains to be seen how well this works in practice - it's not just that there will be gaps in the stack, thunks need to save and restore the stack otherwise we are back to the evaluation stack rather than the call stack. My plan was to enable stack tracing in GHCi because we already track source code locations at a fine granularity for the debugger and the performance overhead is less of an issue there, but we could also have a compile-time option too.
 
Stack tracing in GHCi would already be a great start IMHO. If it all works out, you can still consider support for compiled code.
 
+Simon Marlow I'd like to get some details on your idea. (I implemented stack tracing support for SML/NJ a few years ago, and I wonder if there are any similarities despite ML not being lazy...)
 
I've never seen something get 48 +1's before! I'd turn this on, and take any performance hit, if it addresses the what called the head-of-empty-list shortcoming.
 
I agree with Andy. Having programmed in strict Haskell I'd say it's biggest advantage is the stack trace on error. 
 
I never get IO errors, except the odd division by zero, but I do get lots of "pure" erorrs (Left, call to failure continuation, etc.) and have an ugly combination of source preprocessing, passing "caller" strings around, and keeping a stack manually in a Reader. Of course it would be blatantly non referentially transparent to get a traceback in pure code, but I would totally use an unsafeGetTraceback if the results are just destined for a log file anyway.

I don't know if what Simon's thinking about enables that, but if it did I could happily get rid of a lot of hacky workarounds and spend much less time tracing errors while debugging.
 
+Manuel Chakravarty Patient: It hurts when I shoot myself in the foot.
Doctor: I'm going to put your arms in casts so you can't reach the gun...
 
Ask your doctor if Haskell is right for you. Side-effects include: nothing.

Credit: saw it on Ivan Tarasov's status first :)
 
Intel's reflect language (used in the Forte verification system) has stack traces. Reflect is itself a lazy language; so there's at least one example of stack traces working well in a lazy language out there. Maybe a reflect expert (+Jim Grundy ?) can comment further..
 
reFLect does indeed have stack traces, but it wasn't me who designed them - and I personally didn't use them much. ReFLect also has a pretty cool debugger, also not my doing, and not something I used much. I always liked to print out my code, disappear into a room, and meditate.
Add a comment...