>
> 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 mechanism.
> I also recall it prompted Dave Herman to sketch the design space of
> (single-frame) continuations for JS:
> https://mail.mozilla.org/pipermail/es-discuss/2010-April/010894.html
>
> I have to throw up a red flag and claim some naivety/ignorance here. Even
after reading those links, I'm confused on what "single frame continuations"
means. Perhaps what I have in mind is like that, but perhaps not, and I need
a little help in understanding better the implications of that terminology.
what is a "single-frame"? I *think* I roughly understand a 20,000ft level
idea of what continuation is.
> 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 what you want (and I feel it goes pretty
> far), why commit to a lifetime of pain?
>
> As I said, I'm confused, so I'm not sure where my idea fits in the spectrum
of what you're suggesting. Is my idea closer to the simple mechanism
"single-frame continuation" side or is it closer to the "whole hog" side?
I feel like my idea is pretty simple and limited compared to what I've seen
from the broader scope ideas of full program continuations, true
concurrency, etc. But maybe I'm in completely the wrong "frame" of reference
and my idea is way far out there in complexity?
> Solving these problems was the
> point behind the shallow continuation proposal that we worked on. Does
> the generator strawman build on that work, or does it still fail to
> preserve locality?
>
>
OK, so is "shallow continuation" the same as "single-frame continuation" or
are we now talking about different concepts? Again, on the surface, "shallow
continuation" sounds like it might be akin to what my idea is, but I may be
completely wrong.
> My understanding of Kyle's proposal was that he did not want to
> introduce real continuations, but this was more of a syntax for a
> specialized callback chain, reducing the verbosity of anon functions,
> callback registration.
>
> In my naive understanding of the words, I think what I want to introduce is
statement-localized continuations.
I want for a statement, which can consist of two or more expressions, any or
all of them being function calls which can chose to yield/defer/suspend
their completion asynchronously.
Only a statement which would use the @ operator on two or more expression
operands would be able to take advantage of this statement localized
continuation, though. A function that called `p.defer()` inside itself, but
which was called in a normal expression/statement without @ operator, would
simply complete and program execution would continue as normal. Of course,
the function would still be able to complete asynchronously at a later time,
just like a callback to setTimeout can.
function foo() {
console.log("foo");
}
function bar() {
console.log("bar");
}
foo() @ bar(); // normal sync statement that prints "foobar".
function foo() {
var p = promise;
setTimeout(function(){
console.log("foo");
p.fulfill();
},1000);
p.defer();
}
function bar() {
console.log("bar");
}
foo() @ bar(); // async statement, which will print "foobar", but not until
1000ms from now.
And what I mean by "statement-localized continuation" is that
yield/defer/suspend/continuation would only affect that single statement
with the @ in that case, and any statements after the @ statement would
continue synchronously if the @ statement indeed gets suspended at any point
during its evaluation.
So:
function baz() {
console.log("baz");
}
baz() @ foo() @ bar();
console.log("yes");
would result in "bazyes" immediately, and 1000ms from now, "foobar" right
after it.
Does that make any more sense in terms of clarifying my idea, or does it
just complicate things worse?
--Kyle
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
