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
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 have
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 encounters and
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
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 functions
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
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
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
-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
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);
} catch
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 as in
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. That
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, evaluation of
On Wed, Dec 8, 2010 at 8:48 AM, Getify Solutions get...@gmail.com 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
14 matches
Mail list logo
