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).
> 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
> 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.
> complicated library to use it? And even with such a library, it's still
> much more complicated to use than a simple "delay" keyword.
> "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
> For instance, private names cannot be implemented today and they answer to
> 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
> => 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
> There is also a trick with calling postMessage to send yourself a message:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss