<br><br><div class="gmail_quote">On Tue, Jan 17, 2012 at 2:56 PM, Jussi Kalliokoski <span dir="ltr"><<a href="mailto:jussi.kalliokoski@gmail.com">jussi.kalliokoski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hey everyone!<br><br>I'm new here, although I often read the mailing list, so, hi!<br><br>Anyway, I've been thinking about unblocking sleep semantics for ES, meaning that you could write functions that you do asynchronous things, while preserving the code flow. An example could be the require() function, familiar from node.js, used like this:<br>


<br>require('foo.js').foo();<br><br>However, when you go to the browser world, the modules usually have to be loaded asynchronously, if similar semantics is used, meaning that you would have to use AMD or similar patterns. Also, anything that loads 3 or more files in node.js before doing something is going to be spaghetti without some of the various frameworks designed for that, and even then it isn't pretty. Writing a CLI build tool in node.js is a nightmare.<br>


<br>The remedy I'm suggesting is unblocking sleep semantics. Many people complain that ES doesn't even have sleep(), etc and non-blocking isn't the answer for everything. However in the event-driven model of ES as it's mostly used, things like sleep() don't make much sense, since asynchronous nature is the very power of ES. What we need is actually mainly sugar, making your code look prettier, make it easier to follow. And so I came up with this suggestion (for which I have two possible syntaxes for, verbose and less verbose, but more on that later):<br>


<br>Example: sleep()<br><br>function sleep (time) {<br>  var ready = return function;<br>  setTimeout(ready, time);<br>}<br><br>sleep(5000)<br>// Do something<br><br>So, the core idea of my suggestion is to block the stack and save it for later (until the ready is called), but block nothing but the active stack! Meaning any event listener or else could fire while the sleep is going on. This would bring some funny way of concurrency to JS as well. As you can see here, the semantics is fully backwards compatible (this would be a syntax error in ES5, no additional reserved words or operators). The return function markup would return a function that follows the normal async callback pattern ( callback(err, value); ), and when it's called, it will either return a value or throw respectively at the callstack where the active function has been called.<br>


<br>I have a slightly more complex semantics for this as well, but I personally prefer this one as it's more lightweight and even further backwards compatible.<br><br>For a more complex example and the more verbose semantics, see: <a href="https://gist.github.com/7c5e476e056800f94493" target="_blank">https://gist.github.com/7c5e476e056800f94493</a><br>


<br>So, let me know what you think, and if I was unclear about something.<br><br>Cheers,<br>Jussi<br></blockquote><div><br></div><div><br></div><div>You can get these semantics with generators plus a library (see Dave Herman's task.js [1] as a great example). As generators your `return function;` special form would be spelled spelled `yield` instead, and as shallow continuations this style avoids the potential interleaving hazards implied by your proposal (the inherent run-to-completion violation of fibers).</div>

<div><br></div><div>[1] <a href="https://github.com/mozilla/task.js">https://github.com/mozilla/task.js</a></div></div>