I thought a lot about a reversible programming language, a long time ago...<p>The biggest problem with one is that there would be a huge overhead -- both in execution time and memory used for a truly "reversible" language.<p>I thought at the stack level back then -- basically one of the things that would need to be accomplished would be that a reversible program would have to store old states of the stack, should they be necessary to be reverted...<p>But now I'm thinking to myself...<p>What if the reversibility of a program was implemented at the function level?<p>In other words, ignore the stack (at least temporarily)... and look at each function (procedure/method/routine -- call it what you will, I'll use the term 'function' to apply to all of them) in terms of the memory that it changes, and only in terms of the memory it changes...<p>See, a virtual machine that emulates instructions would be great for this... you reprogram on the instruction level, such that:<p>Did this instruction change memory? Yes? OK, now record that change somewhere, like in a hash that ties this change to this invocation of the function (another point... each function would need a unique "invocation ID"... time consuming to say the least, but that's a sub-discussion)...<p>So now we know (at the cost of tremendous speed! <g>) which functions changed which memory when!<p>And of course, if a function say copies a gigabyte worth of data, then not only is the system slow, but that one function invocation -- would waste an extra gigabyte of memory to keep track of that memory's previous state!<p>But it could be done...<p>Maybe the solution (or one possible solution) would be to implement "memory change tracking" (for lack of a better term!) at the function level, and so, the program author, via compiler assistance, could determine what functions could be "memory change tracked" and which wouldn't.<p>Or, you could implement a system where the memory change tracking kicks in at a certain point (say, when you're debugging and know that a vicious bug is imminent, and you want to find out more about it -- so then you turn on the "full reversibility" aspect of your program!)<p>Or (even better!) -- don't use the VM instruction tracking, add a feature to a compiler to generate additional instructions to do the tracking (much faster than using a VM)...<p>But, no matter which way, it will be slow, it will consume tons of CPU cycles, and it (depending on what your program does) will eat memory like no tomorrow!<p>Still... in a development environment, to find a particularly nasty and elusive bug... it might be worth it...