Generator functions in EVM and long-range transactions?

Just a crazy and quick idea:

What if the EVM could suspend/resume its execution like the Javascript VM can do?
Something like js generator functions?

function* gen() public returns (uint) { 
  yield 1;
  yield 2;
  yield 3;
}

It could enable some kind of long-range transaction that could last for multiple blocks. It could be useful for cross-shard calls.

EVM runtime could keep the tx memory state between blocks without storing it to disk. If the tx doesn’t finish in Nmax blocks, it fails. To recover the execution state of some long-range transaction running at block N, a node could always replay it from the beginning at some previous block.

Most probably the idea is not new, but I have not found any similar discussions.
Do you have any hints?

You could implement this with the current EVM using state.

For the EVM you should be thinking about CPU-level instructions. Javascript doesn’t require additional CPU instructions; it just defines an async syntax that uses the same instructions as C. There’s nothing you can do in JS that you can’t do in assembly.

What I think you want is a solidity programming language feature that would manage the state for you. I’m generally opposed to that because it hides from the programmer the gas costs of their abstractions.

I suppose, you don’t understand me yet.

No, unfortunately you can’t do it now because the EVM memory doesn’t persist between transaction calls.

My idea is exactly to let the memory persist between transaction calls (for the limited time of some blocks) by keeping it in the memory, but without persisting it into the contract state. It will make the generator-like functions in solidity and “long-range” transactions in ethereum possible.

The JS generator function in my post above is just an example.

As I mentioned, I don’t suppose to write the suspended EVM state into the contract state. I suppose the EVM can just keep it in memory without to dispose it. Yes, the total memory footprint grows because many transactions can go into the suspended state at the same time, but for every single transaction there is no additional resource usage. So I see no problem with gas calculation.