> 4. Control of execution (that is, the actuall calling of a function) is
> linear in the chain in the calling code, rather than being controlled by the
> code inside a function.
>
Another reason I feel it's important to address being able to retain control
of the execution of the chained functi
>
> Lastly, I'd say that function signatures which currently accept a
> callback also don't *have* to change. In fact, there may be some value in
> allowing both styles (existing callbacks, and my new proposed style) to
> co-exist in the same function, giving the calling developer the freedom to
>
> I think given the side effects wanted these are the list of features in
> this proposal:
>
> 1. code run in this "statement" does so at the first opportune moment (sync
> runs immediately)
> 2. code in this statement does not start execution until some condition is
> true
> 3. code that encount
>
> No, that's not the case. That code was not hypothetical: it works in
> SpiderMonkey using extensions that have been around for several years. You
> might want to take some time to explore generators by following the docs
> that Mike linked to, and by playing with SpiderMonkey.
>
OK, clearly I
I really like the proposal, but think the syntax is confusing many of us.
I think that the proposal is closer to post hooking than continuation in
spirit. It appears that the syntax is misleading but reading the text of the
desired effects promise.defer() is acting like a point to hook the next pa
On Dec 9, 2010, at 3:27 PM, David Herman wrote:
>> I'm not trying to open the can-o'-worms around block level changes. The
>> above code suggests that a 'yield' suspension of execution is local to the
>> nearest container { } block, in this case the try { } block.
>
> No, that's not the case. T
> I'm not trying to open the can-o'-worms around block level changes. The above
> code suggests that a 'yield' suspension of execution is local to the nearest
> container { } block, in this case the try { } block.
No, that's not the case. That code was not hypothetical: it works in
SpiderMonkey
On Thu, Dec 9, 2010 at 12:22 PM, Getify Solutions wrote:
> 1. I'm not trying to open the can-o'-worms around block level changes. The
> above code suggests that a 'yield' suspension of execution is local to the
> nearest container { } block, in this case the try { } block
No, as implemented in JS
>
> This reminds me of a proposal by Kris Zyp a couple of months ago
> ("single frame continuations")
> https://mail.mozilla.org/pipermail/es-discuss/2010-March/010865.html
>
> I don't think that discussion lead to a clear outcome, but it's definitely
> related, both in terms of goals as well
>
> var task = new Task(function() {
> var request = new HttpRequest();
> try {
> var foo = yield request.send(this, "foo.json");
> var bar = yield request.send(this, "bar.json");
> var baz = yield request.send(this, "baz.json");
> }
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The generators from JS 1.7 are too specific to provide much help with
promises, IMO. Adding a yield operator fundamentally alters the
semantics of the entire surrounding function, violating the principle
of locality. Consequently you need special mec
It might surprise some who know me to hear this, but I agree with Dave
on this. There's a huge gap between the single-frame mechanism and
going the whole hog. Going all out does buy you some expressive
power, but at the cost of complicating everything. If the simple
mechanism gives you most of w
PS To be concrete, here's an example code snippet using my jstask library that
chains several event-generated actions together in a natural way (i.e., in
direct style, i.e. not in CPS):
var task = new Task(function() {
var request = new HttpRequest();
try {
var fo
I pretty much abandoned that line of investigation with the conclusion that
generators:
http://wiki.ecmascript.org/doku.php?id=strawman:generators
are a good (and well-tested, in Python and SpiderMonkey) design for
single-frame continuations. They hang together well; in particular, they don
>
> The spirit of the proposal is that this special type of statement be a
> linear sequence of function executions (as opposed to nested
> function-reference callbacks delegating execution to other code).
>
> The special behavior is that in between each part/expression of the
> statement, evaluati
On Wed, Dec 8, 2010 at 8:48 AM, Getify Solutions wrote:
> I am aware that I'm kicking a potentially angry beehive by bringing up this
> topic, but I wanted to just have some discussion around if there's any
> possibility that JavaScript can, in the near term, have a native mechanism
> added to it
[+ravi]
Hi Kyle, you may also be interested in taking a look at the strawman at <
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency> and the Orleans
paper and video just announced in the email below. One lesson to take from
these (and similar systems going back to Actors) is: once you su
I am aware that I'm kicking a potentially angry beehive by bringing up this
topic, but I wanted to just have some discussion around if there's any
possibility that JavaScript can, in the near term, have a native mechanism
added to it for better managing of sync vs. async coding patterns, without
ne
18 matches
Mail list logo
