"delay" keyword

Brendan Eich brendan at mozilla.org
Thu Jul 5 09:22:03 PDT 2012


Patrik Stutz wrote:
> I've read the articles you linked to and still think that 'delay' 
> would be a great idea! I think this 
> <http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/> post 
> is wrong in many things.

Asserting something you don't back up is poor form, at least around 
es-discuss at mozilla.org.

> In my opinion, "coroutines" would be even simpler to implement 
> (depending on the current design of the engine).

This is simply false. Saving one stack frame is always easier to build 
and optimize (or locally deoptimize) than saving an arbitrary number of 
stack frames (including ones inlined away by optimizing JITs).

> Also, using generators is complicated as hell and in the end still 
> does nothing useful since "yield" is not asynchronus at all. All the 
> libraries that use generators do a lot to make you feel like it were 
> asynchronous behind the scenes, but it isnt.

You need to define your terms. 'yield' does not imply an event loop 
turn, if "event loop turn" is what you mean by "asynchronous".

That's a benefit: generators are useful for implementing iterators (the 
easiest way to implement an iterator is by writing a generator). They're 
a simpler tool.

On Ecma TC39, we do not standardize high-level combinations of 
primitives that compose neatly. We standardize primitives and let 
library authors sort out the best combinations on github.com.

If it's obvious what the next higher-layer primitive should be, we 
standardize quickly. But we do not jump out three or ten moves on the 
chess board -- that's a good way to lose.

> Do you really want to add a feature to JavaScript, for that you need a 
> complicated library to use it?

Yes, as a matter of fact. Many languages (e.g. VB) have gone south with 
"scenario solving" by adding complex features that are not built on 
compositional primitives.

> And even with such a library, it's still much more complicated to use 
> than a simple "delay" keyword.

Try putting 'delay' deep within a function nest -- nothing simple then 
in reasoning about data races, what invariants were lost.

> While generators & libraries for it would overcomplicate JavaScript, 
> "delay" would be dead simple to use.

Stop asserting something you haven't proven, which has obvious 
counterexamples.

> It would fit much better into the language since the rest of the 
> language is also designed very simple.

Also stop using "very" and "simple" in arguments here. "Very" is 
deadwood, and you'll need to count entities by some shared way of 
counting to persuade people of "simple".

> all you'd have change in the example is use something else than 
> setTimeout, and make the delay a function call instead..

'delay' cannot be a function call, it must be a special form so engines 
can analyze for it and deoptimize accordingly.

> Cool! But what are the alternatives to "setTimeout" on the browser 
> side wich dont have any delay?

See setImmediate, draft at

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html

/be
>
>
> 2012/7/4 Jussi Kalliokoski <jussi.kalliokoski at gmail.com 
> <mailto:jussi.kalliokoski at gmail.com>>
>
>     I have to correct myself; I just realized, you *can* actually make
>     it a custom keyword instead of a function call. More on this later. ;)
>
>
>     On Wed, Jul 4, 2012 at 7:39 PM, Jussi Kalliokoski
>     <jussi.kalliokoski at gmail.com <mailto:jussi.kalliokoski at gmail.com>>
>     wrote:
>
>         I think the generators address this issue already, to some extent.
>
>         But regardless, you might be surprised to find out that this
>         is possible already (without generators), but this is a little
>         secret I've been holding in my pocket, all you'd have change
>         in the example is use something else than setTimeout, and make
>         the delay a function call instead... I'm writing a blog post
>         about it and will be sure to share with the group. ;)
>
>         Oh and btw, if there was a keyword like this, I don't think
>         the timeout would always occur *during* the delay, as
>         setTimeout(..., 0) doesn't necessarily mean now, as opposed to
>         a DOM event such as postMessage or the user clicking somewhere.
>
>         Cheers,
>         Jussi
>
>         On Wed, Jul 4, 2012 at 7:19 PM, Patrik Stutz
>         <patrik.stutz at gmail.com <mailto:patrik.stutz at gmail.com>> wrote:
>
>             Hi guys!
>
>             Today, a really cool idea for a new keyword in JavaScript
>             came to my mind. It's called 'delay'.
>
>
>                 What does the |delay| keyword ?
>
>             The |delay| keyword does nothing more than stop the
>             execution of the current stack and immediately continues
>             to the next task in the queue. But that's not all! Instead
>             of discarding the stack, it adds it to the end of the
>             queue. After all tasks before it are done, the stack
>             continues to execute.
>
>
>                 What is it good for?
>
>             |delay| could help make blocking code non-blocking while
>             it still looks like synchronous code. A short example:
>
>             |setTimeout(function(){
>
>
>
>
>                  console.log("two");
>
>
>
>
>             },0);
>
>
>
>
>             console.log("one");
>
>
>
>
>             delay;  //since there is currently another task in the queue, do this task first before continuing
>
>
>
>
>             console.log("three");
>
>
>
>
>
>             //Outputs: one, two, three
>
>
>
>
>             |
>
>             This simple keyword would allow us to create a
>             synchronous-looking code wich is asynchronous behind the
>             scenes. Using node.js modules, for example, would no
>             longer be impossible to use in the browser without trickery.
>
>             There would be so many possibilites with such a keyword!
>
>             What do YOU JAVASCRIPT DEVELOPERS think about it? What do
>             you think can I do to bring this into the new ECMAscript
>             Specification?
>
>             Please disuss as much as you want! :)
>
>
>             _______________________________________________
>             es-discuss mailing list
>             es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>             https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list