| > 'pretend X doesn't exist' is in my mind 'speculate that X isn't enabled'. It really means the same thing doesn't it? Not when you're talking about needing "dynamic analysis", which is what made me not understand the way you were using that word. > It does make compilation more complicated because you need to be able to restore the full debug state of the application, which means storing some results you may not choose to do otherwise, and storing extra meta-data. You don't need to, in the general case. > Debuggers can be a formally or informally specified part of the language, and their behaviour may have to follow rules about which intermediate results are visible which may constrain your compilation. > My argument is: if you do treat debugging as speculation then your model is simpler and easier to work with and you don't need two kinds of deoptimisation. Real languages are implemented this way. I suppose, but that's only one option. You could make the deoptimization for debugging much weaker or nonexistent, and that would be a valid option too, without having to give up simplicity. And separately, wanting to change the value of a const while debugging is a valid use case too. But once you support that, there's no reason a never-written let needs to be optimized differently from a const. |