> You should no better than that. It is only free in pure functional languages if they keep every single world around
Which a debugger for a purely functional language would do for you. Which is why I said it would be almost trivial to create this kind of tooling in such a language.
> So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same.
Not sure I agree. Save the world after the fact would seem to require much deeper integration with the abstract machine to capture the evaluation context. I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create.
> Which a debugger for a purely functional language would do for you.
Yes, you are already checkpointing if you have such an interpreter, not that I think many programs would actually qualify.
> I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create.
Most production language reverse debugging techniques are similarly shallow because they work mostly at the OS level (GDB), it isn't hard to capture evaluation context when you capture everything.
How is reverse debugging working out for Haskell then? I assume, since it is trivial over there, it must be common?
> How is reverse debugging working out for Haskell then?
The Elm debugger I posted above is a perfect example. Unlike your GDB example, it doesn't only work for a subset of x86 instructions or require monumental effort to implement. It's a high-level domain-specific debugger, that was simple to specify and build. For those of us that want to write high-level code with many layered abstractions, working one-word-at-a-time using GDB is simply not a great way to debug, even if it does now sometimes work backwards. We want to easily build our own debuggers.
Which a debugger for a purely functional language would do for you. Which is why I said it would be almost trivial to create this kind of tooling in such a language.
> So choose between "save the world because that's what we already do" or "save the world after the fact," it is pretty much the same.
Not sure I agree. Save the world after the fact would seem to require much deeper integration with the abstract machine to capture the evaluation context. I was merely pointing out that this integration is shallow in a purely functional language, and such a tool would be easy to create.