[Haskell-cafe] Re: GSOC Haskell Project

[Thomas Schilling]

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.