[Haskell-cafe] Re: how do you debug programs?
Neil Mitchell
ndmitchell at gmail.com
Wed Sep 6 10:51:17 EDT 2006
Hi
> > Yes, and if the compiler is this clever, it should also be free to
> > replace them back at debug time.
>
> And where does that get us? You snipped the salient bit
> where I said that you'd be debugging a different programme.
In Visual C there are two compilation modes. In debug mode, if you
create a variable "i" it WILL be there in the compiled version. It
won't be merged with another variable. It won't be constant folded. It
won't have its value globablly computed and stored. It won't be placed
only in the register. In release mode all these things can (and do)
happen. I'm not saying Haskell compilers aren't free to optimize, but
maybe there is a need for one that is this "debug mode" style.
> At no point have I ever
> used a debugger on a Haskell programme.
Because you couldn't find a working debugger? ;) If one had been
there, just a click away, would you never have been tempted?
> It may sound like that to you, but the arguments why
> debugging is a bad thing are quite strong. There are almost
> certainly bugs in my Haskell code. Would a debugger help me
> find them? Not in the least, because none of the testcases
> I've used provokes them. Would it help when one is provoked?
> I don't think so, because either the logic is right and
> there's a slip up in the coding, which is usually easy to
> find from the new testcase, or the logic is tortuous and
> needs replacement.
Let take for example a bug I spent tracking down in Haskell this
weekend. The bug can be summarized as "Program error: pattern match
failure: head []". And indeed, thats all you get. A quick grep reveals
there are about 60 calls to head in the program. In this instance I
have the choice between 1) crying, 2) a debugger, 3) a lot of hard
work. [Of course, knowing this situation arises, I had already
prepared my getout plan, so it wasn't a massive problem]
Thanks
Neil
More information about the Haskell-Cafe
mailing list