I guess the fiber/coroutine support would be a better solution to this problem? If this works like I think it should work, the code can decide itself when it is a good time to yield control back to the environment instead of freezing execution in a random location until the next frame.
For instance when evaluating NPC AIs it may be important that an NPC isn't left dangling in a random state at the end of a frame, but either has finished evaluating, or hasn't started yet.
Code cannot decide when to yield because it doesn't know how many NPCs I am running in one frame. Maybe I need 10, maybe 2 longer and 8 just quickly for long running/low complexity jobs. If the limit is reached in the middle of "if" statement, e.g.
if x < sin(5) + cos(20) then y = 5;
If "x" and "sin(5)" was evaluated but not "cos(20)" then it should just remember VM state and continue next time. I did this in JS and it worked great for distributing NPC load between frames (https://twitter.com/dusan_halicky/status/1173924435923001344) and it didn't required any understanding of the code (I didn't need to carefully check when I need to stop execution), just VM snapshot and continue next frame.
Since it’s a small language that already supports yielding for I/O, it shouldn’t be too hard to automatically insert an instruction into all loops to check if they need to pause. You could write it manually to prototype.
(Or at least I assume it works that way based on studying Wren.)
For instance when evaluating NPC AIs it may be important that an NPC isn't left dangling in a random state at the end of a frame, but either has finished evaluating, or hasn't started yet.
https://thakeenathees.github.io/pocketlang/language-api-fibe...