hannobraun
commented
3 hours ago There's another thing I just thought of: host effects. Those have effects outside of the runtime, so the runtime can't do anything to rewind them. I think for a start, it would be enough to just refuse to rewind host effects. Later on, there could be infrastructure for effect rewinding, with the host deciding which effects can be rewound and which can't.
I've written a bit about this topic before: 2024-04-23, 2024-07-03
Description
If a code update causes the runtime to fail, this isn't fixable without restarting the runtime, and thus the program. It would be much better, if it was possible to rewind the runtime to an earlier state, then fix the issue with an additional code update.
Proposed Solution
Each instruction can only interact with the runtime in limited ways. Pop a value, push a value, and probably a few more. I've come to call these elementary operations "micro-transactions".
If we logged those micro-transactions to a buffer, we could later undo them. Since the number of micro-transactions is limited, there wouldn't need to be much code to implement "undo" functionality. It also wouldn't require any per-instruction undo code. If an instruction pushed
x, all we need to undo is pop. We don't need to care whetherxwas the result of an addition, subtraction, or something else.However, before attempting this, it would be advisable to simplify the instruction set first. Right now, some of the instructions are overly complicated. I've added a bunch of implementation notes on
Instructionswith thoughts on that. Making those simplifications would be beneficial in its own right, and then make implementing this solution easier.Related Issue
This is a more specific follow-up issue to https://github.com/hannobraun/caterpillar/issues/50, which has largely been addressed.