On 20/10/2011, at 23:37, Brendan Eich wrote:
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
the assert_invariants() at the next line might run in another turn of the
event loop (when f() resumes), just as the callback does.
No. Nothing in JS today, since it lacks coroutines or call/cc, can
On 21/10/2011, at 11:07, Jorge wrote:
And this has several (valuable, imo) advantages:
- We aren't trashing the call stack on every async call: we can finally debug
properly!
- We can (finally!) catch the exceptions where and when it matters.
- We can loop and control flow in the usual
You can disagree with anything if you're allowed to change the terms of the
discussion. :)
Brendan said JS is run-to-completion, which means that if you call a function
and control returns to you, no intervening threads of control have executed in
the meantime. But then you changed his example
On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
Mark Miller Q library:
https://github.com/kriskowal/q
Did you see
https://github.com/kriskowal/q/tree/master/examples/async-generators yet?
In my experience,
Hi Kris,
Your proposal has a lot of similarities to
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
which was proposed this past spring.
I'm not sure I follow what's top-down vs bottom-up about the two different
approaches. Let me suggest some terminology that has
On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
Mark Miller Q library:
https://github.com/kriskowal/q
Did you see
On Fri, Oct 21, 2011 at 10:20 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
On Fri, Oct 21, 2011 at 9:41 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 21, 2011, at 9:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris Zyp /
Mark
On Oct 21, 2011, at 10:20 AM, John J Barton wrote:
My comment is entirely subjective and intended to be positive about Q.
We like Q too. :-)
The examples on the async-generators page cites above are clearer than the
ones on the MDC generators page because they focus on next(). The strong
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call expression
like this:
try {
response = asyncFunction(request); //might suspend execution
}
catch (e) {
//whatever
}
//our code continues here
we needed to write
On 21/10/2011, at 21:23, Dean Landolt wrote:
On Fri, Oct 21, 2011 at 3:20 PM, Jorge jo...@jorgechamorro.com wrote:
On 21/10/2011, at 17:40, Eric Jacobs wrote:
Jorge,
Would it still be satisfying to you if instead of writing the call
expression like this:
try {
response =
Jorge wrote:
or some other creative way of statically encoding the might suspend
execution condition into the syntax?
Yes, of course, it would be fine. Why ?
Because this is the crux of the run-to-completion debate that we're
immersed in.
Right now, JS has run-to-completion, where
On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote:
The catch is, of course, that all code which either can yield, or can call
other functions which yield, must have the yield keyword there, to mark
that run-to-completion invariants will end at that point. This seems like a
very reasonable
On Fri, Oct 21, 2011 at 10:46 AM, Mark S. Miller erig...@google.com wrote:
On Fri, Oct 21, 2011 at 10:20 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
In particular, Q simplifies joining parallel async operations (XHR,
postMessages, 'load', 'progress' events). Of course it may well
Brendan Eich wrote:
On Oct 21, 2011, at 12:49 PM, Eric Jacobs wrote:
The catch is, of course, that all code which either can yield, or can call other
functions which yield, must have the yield keyword there, to mark that
run-to-completion invariants will end at that point. This seems like a
On Oct 21, 2011, at 2:03 PM, Eric Jacobs wrote:
As a language end-user, I'm not sure that I would (or should) be concerned
about the distinction between a deep continuation and a chain of shallow
continuations. After all, the stack is just a chain of frames, and the
mechanism by which
On 10/21/2011 11:01 AM, David Herman wrote:
[snip]
But there's more to it than just the interface. You fix a particular
scheduling semantics when you put deferred functions into the
language. I'm still learning about the difference between the Deferred
pattern and the Promises pattern, but
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync XHR)
JS has run-to-completion execution model now. You can model
assert_invariants();
f();
assert_invariants_not_affected_by_f_etc();
where etc means functions
On Thu, Oct 20, 2011 at 9:44 AM, Jorge jo...@jorgechamorro.com wrote:
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync
XHR) JS has run-to-completion execution model now. You can model
assert_invariants();
f();
On Oct 20, 2011, at 6:44 AM, Jorge wrote:
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync
XHR) JS has run-to-completion execution model now. You can model
assert_invariants();
f();
On 20/10/2011, at 18:38, Brendan Eich wrote:
On Oct 20, 2011, at 6:44 AM, Jorge wrote:
On 19/10/2011, at 23:34, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync
XHR) JS has run-to-completion execution model now. You can model
On Oct 20, 2011, at 12:59 PM, Jorge wrote:
assert_invariants();
f(); //might suspend execution
assert_invariants(); // perhaps yes, perhaps no. There's no guarantee
either.
return;
(Please trim cited text -- I know gmail hides it, which is a bug, but most mail
user agents show it, and
The topic of single-frame continuations has been discussed here before,
with the current state of ES.next moving towards generators that are
based on and similar to Mozilla's JS1.7 implementation. Generators are a
powerful addition to the language and welcome (at least by me). However,
I
This is a really great idea, Kris! A few comments inline...
On Wed, Oct 19, 2011 at 1:11 PM, Kris Zyp k...@sitepen.com wrote:
The topic of single-frame continuations has been discussed here before,
with the current state of ES.next moving towards generators that are based
on and similar to
Kris Zyp wrote:
I believe that the overwhelming need that is continually and
constantly expressed and felt in the JS community in terms of handling
asynchronous activity is fundamentally a cry for top-down controlled
single-frame continuations (obviously not always stated in such terms,
On 10/19/2011 12:29 PM, Dean Landolt wrote:
This is a really great idea, Kris! A few comments inline...
[snip]
If the value is not an object with a then property that is a
function, the operand value is the immediate result of the
evaluation of the yield expression and execution
On Oct 19, 2011, at 12:55 PM, Eric Jacobs wrote:
Kris Zyp wrote:
I believe that the overwhelming need that is continually and
constantly expressed and felt in the JS community in terms of handling
asynchronous activity is fundamentally a cry for top-down controlled
single-frame
On Oct 19, 2011, at 10:11 AM, Kris Zyp wrote:
The topic of single-frame continuations has been discussed here before, with
the current state of ES.next moving towards generators that are based on and
similar to Mozilla's JS1.7 implementation. Generators are a powerful addition
to the
On Oct 19, 2011, at 2:34 PM, Brendan Eich wrote:
The other objection is that (ignoring some evil native APIs such as sync XHR)
JS has run-to-completion execution model now. You can model
assert_invariants();
f();
assert_invariants_not_affected_by_f_etc();
Contrast with generators,
28 matches
Mail list logo
