[Haskell-cafe] monadic debugging

[Bernie Pope]

On 16/04/2008, at 10:16 AM, Thomas Davie wrote:
>
> On 16 Apr 2008, at 00:04, Bulat Ziganshin wrote:
>> Hello Vasili,
>>
>> Wednesday, April 16, 2008, 2:53:32 AM, you wrote:
>>
>>>     I have an Linux executable of my Haskell library and test
>>> case. I see there are several debuggers, e.g. Buddha, Hat, etc.
>>> Which debugger is currently preferred for monadic (imperative)  
>>> code? Thanks.
>>
>> i use print mainly :)  btw, there is also built-in ghci debugger, i
>> suspect that it's closest one to the usual debuggers and most useful
>> one for imperative code (but i never tried anything, so don't  
>> trust me :)
>
> Having worked lots on Hat, and studied all (I hope or I've got a  
> hole in my research) of the debuggers out there, I'd have to say  
> that debugging monadic code is still very much an unsolved  
> problem.  Putting print statements in is probably your best option.
>
> You may want to try hat-delta, or buddha's functional mapping mode  
> -- both of them should be capable of reducing sequences of monadic  
> operations to a single operation and a function map.

I agree with Tom, that debugging monadic code is an open problem.

 From a practical level, I doubt buddha is going to be much help,  
because it has bit rotted, and is unsupported.

Hat allows you to debug the program in different ways, and it gives  
you reduction traces, which can often be useful, so you may get some  
traction there.

But I would try the ghci debugger first. Be warned: it forces you to  
be aware of lazy evaluation, which can be quite hard to understand,  
so you need a bit of practice with it. As for debugging monads, it  
depends on the complexity of the monad. If you are using standard  
monads (and that usually means transformers) then a lot of the  
plumbing will be invisible in the debugger, because breakpoints and  
stepping don't work in the libraries (you would have to copy the  
library code into your workspace, if you wanted to see the underlying  
monad code in action).

I've successfully found bugs in code using the ghci debugger, where  
the code used a continuation transformer, over a state transformer,  
over an IO monad. It was easy enough to follow because I wasn't  
forced to see the plumbing underneath. In particular I wasn't forced  
to see the continuation, or the state, which really helps. Of,  
course, if I did want to see those things then I would have been in  
trouble.

One question that has been in my head for a while now is that if you  
used the Unimo way to build monads, maybe they are easier to debug?  
The Unimo style is intentionally operational, and that may be a  
better fit to debugging, especially in the ghci debugger, which  
requires an operational way of thinking.

Here's a link to the Unimo paper: http://web.cecs.pdx.edu/~cklin/ 
papers/unimo-143.pdf

If you do make some progress with any of the debugging tools it would  
be very useful to hear how it went. We get very little feedback on  
successful debugging endeavours where tools were involved (maybe  
because the tools aren't helpful, it is hard to say).

Cheers,
Bernie.