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.