setTimeout

[mattbierner]

This is an external api but will require changes be made to the interpreter. I think the timeout should be potentially executed after the execution of a statement.

There is only one executing thread of code at a time but multiple 'threads' need to be active in the program context at a time. Some higher level controller then selects the thread to execute next.

For example:

var x = 0;
var y = 0;
function inc(){ ++x; };
setTimeout(f, 1); // Assume time is a number of statements
// Creates a new 'thread' that will call f.
// Check after setTimeout expr statement done to see if should execute.
// Finds zero so no
++y;
// Check again, finds one so yes.
// f executed before next statement. f thread removed from active threads.
// x is 1 here;
++y;
++y;

[mattbierner]

Instead of working at a statement level, I think working at source element level will be more clear. After a block of source elements have been evaluated, the 'threads' will be checked to see which one to resume next. Complications are handling errors, debugging, and return values with setTimeout.

The interpreter should not return until the entire computation, all 'threads', have completed. Even if a timeout is set for an extended period of time, the interpreter should enter a dispatch loop like pattern until which time the 'thread' can be executed.

The returned value from the interpreter should be the result from the program body source elements. However 'threads' can effect the values in the main thread and these changes may be reflected in the returned value.

Debugging points will be hit regardless of which 'thread' they are in. Errors will be captures in the 'thread' and ignored, but they can still be broken on for debugging.

[mattbierner]

Actually this is not specifically required if using newer version of requirejs. However, it may still be worth supporting in the future.