As far as I understand it, when the "future" keyword is hit it woudn't return control to the scheduler; it would introduce a special deferred value. Control would only return to the scheduler when something attempts to 'force' that deferred value.
You can think of these deferred values as being a getter and setter pair, sharing a reference:
var future = function() {
var x;
return {'getter': function () {
while (typeof(x) === 'undefined') wait;
return x;
},
'setter': function(val) {
x = val;
}};
};
In the article, future is a keyword rather than a function, and the getter and setter are called implicitly. The idea is that we can pass around references (the {'getter', 'setter'} pair) however we like without triggering any action; however, once the getter is called it will enter a loop, polling and 'waiting' (switching execution back to the scheduler) as long as the setter's not been called.
The radical part here is the 'wait', which I've made up to illustrate the point, and is the crux of the whole thing. It's basically a cooperative multithreading mechanism. This would let an asynchronous API be turned into a synchronous one, since we just need to wait for the result with a polling loop like my example above.
Whether that's a good idea or not is debatable. Personally I think it's a bad idea; shared mutable state is the cause of all concurrency problems (race conditions, locks, deadlock, livelock, etc.) so it absolutely should not be default or implicit. The idea that 'concurrent' == 'multithreaded' needs to die; multithreading is a dangerous anti-feature which uses a little syntax to hide a whole new language semantics, breaking all intuitions about our code and throwing safety properties out of the window.
Thankfully Javascript hasn't fallen into this trap yet; eg. WebWorkers uses message-passing instead.