Fwd: "delay" keyword

Patrik Stutz patrik.stutz at gmail.com
Thu Jul 5 04:36:37 PDT 2012


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?

Yes, I can. The reason and main use case why I'm requesting delay is, that
I want be able to run node.js modules in the browser without any
modification or trickery. I want be able to make a require function that is
synchronous but does not block.

With the delay keyword, this would look like this:

function loadModule(name,cb){
setTimeout(function(){
 cb({/*my aswesome module*/});
 },0);
}
function requiure(name){
var module;
 loadModule(name,function(m){
 module = m;
});
 while(!module){
 delay;
}
 return module;
}

var myawesomemodule = require("myawesomemodule"); //non-blocking!

With generators, a synchronous but non-blocking require function is simply
not possible. You'd have to modify all your code and add everywhere before
"require" the "yield" keyword. But that's not all! You'd have to wrap every
module definition with another function, which is an absolute pain.

So you see, the node.js module loading problem is not resolvable using
generators. So, when such a simple thing is not possible using generators,
what are they good fore again?

The fibonacci example on MSD doesn't really point that out. Except code
pausing, all that generators can do can also be done otherwise. I've
rewirtten the fibonacci example to demonstrate that:
function fibonacci(){
var fn1 = 1;
 var fn2 = 1;
return{
 next:function(){
var current = fn2;
 fn2 = fn1;
fn1 = fn1 + current;
 return current;
}
 }
}

So, the only "new" thing we got from generators is code pausing. But as we
have seen above, this is in the current form also useless, since we are
still unable to make node.js like modules possible.

 coroutines would require to store stack frames to enable running them
later.

This is also true for generators. The only difference is, that the stored
stack is never deeper that one function call. So, theoretically, every
engine that curently supports "yield" should also be able to store a bigger
stack.

But ok, if it's this limitation to flat stacks that excites you about
generators, I got another idea how we could mix "delay" and generators to
something that makes a lot of sense. What about adding the functions
"callDelayed" and "applyDelayed" to the Function prototype? The would do
exactly the same as "call" and "apply" but with the difference, that they
don't return the result. Instead the return an object that has a
synchronous property "result" or a function "getResult()" and a function
"continue()". After accessing "result", the code pauses until the function
returns a value. In functions, we still would have the "delay" keyword. But
instead of moving the current stack to the end of the queue, it would
remain paused until someone calls "continue()"

function a(){
    delay;
    return "Hello World";
}
var functioncall = a.callDelayed(this);
setTimeout(function(){
     functioncall.continue();
},0);
console.log(functioncall.result); //pauses until "continue()" was called,
then displays "Hello World"

To me, all this is not a feeling- or optinion- thing. I just see that I
can't do what I want do without co-routines. There's definitely a usecase
for them. There are things co-routines can do, that generators can't.


Please note that I'm not really interested in programming new stuff in a
new way. I was really happy with the current JavaScript. The only bad thing
was, that we were not able to load code synchronously but non-blocking. To
make for example node.js modules working in the browser, we needed to
rewrite them or to use some trickery. So, I don't wan't to introduce a new
coding style with "delay", I just want to make *existing code* work using
some new features.

Generators instead are tought to introduce a new way of coding. But since
we were able to do exactly the same in the past using different syntax, it
isn't a really needed feature. *Except of the code pausing using yieald,
tough.*
*
*
*
*





2012/7/5 David Bruant <bruant.d at gmail.com>

>  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)
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/12b140d2/attachment-0001.html>


More information about the es-discuss mailing list