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