Re: Unblocking sleep semantics
Another relevant library that makes use of the same generator trick, but integrated with promises, is Kris Kowal's Q API < https://github.com/kriskowal/q> via Q.async: https://github.com/kriskowal/q/blob/master/examples/async-generators/README.md Event-driven programming without inversion of control, yet without screwing up your callers' invariants, is cool. Cheers, Tom 2012/1/17 Jussi Kalliokoski > Okay, now that I've been re-reading how generators work and about task.js, > it has made me realize my error. Yes, you're right, what I've made is > actually deep continuations, and that's not really what I had in mind. > > Thanks everyone, I'll try to think of a better way to do this (or to find > out if it already exists :] ). > > Cheers, > Jussi > > > On Tue, Jan 17, 2012 at 11:00 PM, Dean Landolt wrote: > >> >> >> On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski < >> jussi.kallioko...@gmail.com> wrote: >> >>> Yeah, I was aware of the coroutines in generators, that's why I said it >>> would be sort of sugar. :) >>> >> >> >> But it's not sugar, it's a different feature. It's the difference between >> shallow and deep continuations. We already have shallow continuations (by >> way of generators). Deep continuations are potentially hazardous. I for one >> would love some sugar for the shallow continuations use-case of generators >> but libraries will do just fine. >> > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
Okay, now that I've been re-reading how generators work and about task.js, it has made me realize my error. Yes, you're right, what I've made is actually deep continuations, and that's not really what I had in mind. Thanks everyone, I'll try to think of a better way to do this (or to find out if it already exists :] ). Cheers, Jussi On Tue, Jan 17, 2012 at 11:00 PM, Dean Landolt wrote: > > > On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski < > jussi.kallioko...@gmail.com> wrote: > >> Yeah, I was aware of the coroutines in generators, that's why I said it >> would be sort of sugar. :) >> > > > But it's not sugar, it's a different feature. It's the difference between > shallow and deep continuations. We already have shallow continuations (by > way of generators). Deep continuations are potentially hazardous. I for one > would love some sugar for the shallow continuations use-case of generators > but libraries will do just fine. > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski < jussi.kallioko...@gmail.com> wrote: > Yeah, I was aware of the coroutines in generators, that's why I said it > would be sort of sugar. :) > But it's not sugar, it's a different feature. It's the difference between shallow and deep continuations. We already have shallow continuations (by way of generators). Deep continuations are potentially hazardous. I for one would love some sugar for the shallow continuations use-case of generators but libraries will do just fine. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
Yeah, I was aware of the coroutines in generators, that's why I said it would be sort of sugar. :) On Tue, Jan 17, 2012 at 10:43 PM, David Bruant wrote: > Le 17/01/2012 21:38, Axel Rauschmayer a écrit : > > More > > material: > http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ > ... and a link to the proposal: > http://wiki.ecmascript.org/doku.php?id=harmony:generators > ;-) > > David > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
Le 17/01/2012 21:38, Axel Rauschmayer a écrit : > More > material: > http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ ... and a link to the proposal: http://wiki.ecmascript.org/doku.php?id=harmony:generators ;-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
More material: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ On Jan 17, 2012, at 21:30 , Dean Landolt wrote: > 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). > > [1] https://github.com/mozilla/task.js -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Unblocking sleep semantics
On Tue, Jan 17, 2012 at 2:56 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
> Hey everyone!
>
> I'm new here, although I often read the mailing list, so, hi!
>
> 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:
>
> require('foo.js').foo();
>
> 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.
>
> 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):
>
> Example: sleep()
>
> function sleep (time) {
> var ready = return function;
> setTimeout(ready, time);
> }
>
> sleep(5000)
> // Do something
>
> 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.
>
> 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.
>
> For a more complex example and the more verbose semantics, see:
> https://gist.github.com/7c5e476e056800f94493
>
> So, let me know what you think, and if I was unclear about something.
>
> Cheers,
> Jussi
>
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).
[1] https://github.com/mozilla/task.js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Unblocking sleep semantics
Hey everyone!
I'm new here, although I often read the mailing list, so, hi!
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:
require('foo.js').foo();
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.
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):
Example: sleep()
function sleep (time) {
var ready = return function;
setTimeout(ready, time);
}
sleep(5000)
// Do something
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.
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.
For a more complex example and the more verbose semantics, see:
https://gist.github.com/7c5e476e056800f94493
So, let me know what you think, and if I was unclear about something.
Cheers,
Jussi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
