"delay" keyword

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Jul 5 05:34:50 PDT 2012


On Thu, Jul 5, 2012 at 1:04 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 05/07/2012 11:08, Patrik Stutz a écrit :
>
> 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. In my opinion, "coroutines" would be even simpler
> to implement (depending on the current design of the engine).
>
> I am not a JavaScript engine implementors (Dave Herman is, by the way),
> but from what I know, coroutines would require to store stack frames to
> enable running them later. If it's not something done already, it may be
> complicated to do. JavaScript engines are engineered for performance of
> today's JavaScript and today, there is no coroutine (this probably stands
> for generators, but some engines already have generators)
>

Just FYI, SpiderMonkey already has stack pause/resume implemented, I think
it has been there at least since Fx8. At least to some extent. What's
missing is a way for JS to leverage this (without hacks). Ugh, I really
need to write that blog post, this is a very complex subject.


>  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.
>
>  Do you really want to add a feature to JavaScript, for that you need a
> complicated library to use it? And even with such a library, it's still
> much more complicated to use than a simple "delay" keyword.
>
>  While generators & libraries for it would overcomplicate JavaScript,
> "delay" would be dead simple to use. It would fit much better into the
> language since the rest of the language is also designed very simple.
>
> Your post contains a lot of opinions, feelings and things that you think
> and adding new features is not really about what a particular person thinks
> in my opinion.
> For any features to be added to the language, nothing is really about
> opinion. It all start with use cases.
> Could you show something that 'delay' enables that is not possible
> currently?
> For instance, private names cannot be implemented today and they answer to
> a need of JavaScript developers who want better encapsulation idioms.
>
> If there is no such thing, is it a major improvement by comparison to what
> is possible today?
> For instance, WeakMaps, Maps and Sets can actually be implemented today,
> but with bad performances or relying on mechanisms with unreliable
> performance, so having them implemented in the language offers some
> guarantees of performance.
>
>
> I am not asking for yes/no answers, but actual code snippets taken out of
> real projects showing how 'delay' would make the code easier to read or
> understand, to reason about.
>
>
> One point made by Dave in his article is very compelling:
> "Once you add coroutines, you never know when someone might call yield.
> Any function you call has the right to pause and resume you whenever they
> want".
> => This makes very difficult to build programs using libraries.
>
> "Generators are a lot like coroutines, with one important difference: they
> only suspend their own function activation."
> => And suddenly, your code is not affected by another function being a
> generator. When you call a function, it either never return (infinite
> loop), returns or throws an exception (which is just a different form of
> return for that matter).
>
>
>
>  all you'd have change in the example is use something else than
> setTimeout, and make the delay a function call instead..
>
>  Cool! But what are the alternatives to "setTimeout" on the browser side
> wich dont have any delay?
>
> setTimeout(f ,0) could work, but has a small delay for historical reasons.
> Microsoft is coming up with setImmediate (I haven't heard anyone
> following)
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html
> There is also a trick with calling postMessage to send yourself a message:
> http://dbaron.org/log/20100309-faster-timeouts
>
> David
>

Yes, the postMessage trick is the one I was referring to, but setImmediate
would probably work as well. In node.js, there's process.nextTick(cb), but
I don't know of a way to pause/resume a stack in node.

Cheers,
Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/fd9e77b0/attachment.html>


More information about the es-discuss mailing list