I was feeling tempted to agree with Sebastian on this (and I still kinda do), but I tested it and I don't see many concerns about it. Although I do see a few.
My initial worry was that this would be stalling the engine's loop, but it isn't. Everything seems to run fine.
keyboard are being updated, you can count delta time as normal, you can print out
system.fps just fine, etc. It seems like the engine is running on separate threads, so everything seems to be working as normal.
I actually feel curious about what @gilles would say about this, as he knows everything that's going on under the hood.
The concerns I still have are just these:
1 - the load order of the game files is unpredictable, so if you spread your project to more files, your loop may start running too soon, before everything is initialized, and you'll get errors and bugs. You could work around that by placing your loop in
init (it still works the same), because
init only gets called after all files are loaded:
init = function()
// loop stuff
2- your loop is going to be slower than the engine's loop. Because it's a microscript loop, not a JS loop. The embedded language is always inherently slower than the host language, because it's being interpreted by it.
I mean, here's the thing, if it works, it works, and if you can't find faults with it in a particular use case, then I don't see any reason for me to try and stop you from doing it. But I'm guessing you'll run into some issues with it, eventually.