[Haskell-cafe] Re: GSOC Haskell Project

Max Bolingbroke batterseapower at hotmail.com
Thu Apr 1 13:37:19 EDT 2010

I still believe that it would much simpler to get some stack traces
out of GHC by just reporting what chain of thunks we are currently
forcing when we get an error. This just requires a way of reifying the
existing STG stack in some user-readable way.

What it doesn't give you is lexical call stacks of any form, but many
people have pursued that goal and failed. The STG stack only tells you
the "dynamic" call stack, and will omit any frames removed due to e.g.
tail recursion optimisation, but at least it gives you *some*
information about where your "head []" error is coming from!

For those interested, there is more discussion of the idea at


On 1 April 2010 18:22, Thomas Schilling <nominolo at googlemail.com> wrote:
> The DrScheme debugger shows backtraces as arrows in the source code.
> It took some getting used to, but it doesn't seem like a bad idea.  I
> believe Leksah has some sort of graphical frontend for the GHCi
> debugger, but I haven't tried it out myself yet.  Maybe you can build
> on top of that.
> Stack traces are rather difficult to implement.  Tristan Allwood
> implemented stack trace support as a GHC Core plugin (see his 2009
> Haskell Symposium paper) but it required quite a lot of recompilation.
>  His stack traces also didn't record any values, just source
> locations.  He also had some problems with the way mutually recursive
> functions with type classes were desugared and, as so often, CAFs
> (constant applicative forms).
> So if you propose to work on that you should have a good idea how to
> overcome such issues it in your application.
> Another problem with stack traces turned on is that they may lead to
> space leaks.  I don't know how big of an issue this is in practise,
> but I'm pretty sure you can't just keep them turned on all the time.
> The GHCi debugger has a tracing mode that can be turned on explicitly
> and allows you to "go back in time" if you hit a break point or error.
>  I believe a good front-end could make this a much more widely used
> feature.
> On 1 April 2010 17:39, Mihai Maruseac <mihai.maruseac at gmail.com> wrote:
>> So, should I change the topic of the project to stack traces instead
>> of visual GUI representation? If this were the case, I will have to
>> find a way to represent those traces in a way that even a beginner can
>> read and understand (my GUI approach was for the beginners).
>> --
>> Mihai Maruseac
>> On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit <dagit at codersbase.com> wrote:
>>> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>>> On 30/03/2010 20:57, Mihai Maruseac wrote:
>>>>> I'd like to introduce my idea for the Haskell GSOC of this year. In
>>>>> fact, you already know about it, since I've talked about it here on
>>>>> the haskell-cafe, on my blog and on reddit (even on #haskell one day).
>>>>> Basically, what I'm trying to do is a new debugger for Haskell, one
>>>>> that would be very intuitive for beginners, a graphical one. I've
>>>>> given some examples and more details on my blog [0], [1], also linked
>>>>> on reditt and other places.
>>>>> This is not the application, I'm posting this only to receive some
>>>>> kind of feedback before writing it. I know that it seems to be a
>>>>> little too ambitious but I do think that I can divide the work into
>>>>> sessions and finish what I'll start this summer during the next year
>>>>> and following.
>>>>> [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/
>>>>> [1]:
>>>>> http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/
>>>>> Thanks for your attention,
>>>> My concerns would be:
>>>>  - it doesn't look like it would scale very well beyond small
>>>>   examples, the graphical representation would very quickly
>>>>   get unwieldy, unless you have some heavyweight UI stuff
>>>>   to make it navigable.
>>>>  - it's too ambitious
>>>>  - have you looked around to see what kind of debugging tools
>>>>   people are asking for?  The most oft-requested feature is
>>>>   stack traces, and there's lots of scope for doing something
>>>>   there (but also many corpses littering the battlefield,
>>>>   so watch out!)
>>> I would be much more interested in seeing the foundations improved than I
>>> would be in having nice things built on them.  In other words, I agree with
>>> Simon that stack traces would be many times more valuable to me than
>>> graphical representations.  Once the foundations are robust, then we can
>>> build nice things on top of them.
>>> Perhaps the reason you're interested in graphical representations is because
>>> you want to help people 'visualize', or understand, the problem.  Not all
>>> visualizations need to be graphical in the GUI sense.  It's really about
>>> representing things in a way that helps humans reason about it.  Getting the
>>> right information to people as they need it is probably the best place to
>>> start.
>>> Jason
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> --
> Push the envelope.  Watch it bend.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list