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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
