> 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 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.
> 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.
Both "single-frame continuation" and "shallow continuation" are terms we've
used informally for the same idea: being able to suspend a single function
activation (aka stack frame) as a JavaScript value that you can use later to
resume the suspended activation.
> 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.
Nobody is recommending full continuations or heavyweight concurrency
facilities. *Especially* if it involves shared-memory threads (which most
straightforward extensions would) -- that will *definitely* not happen in
ECMAScript).
> But maybe I'm in completely the wrong "frame" of reference and my idea is way
> far out there in complexity?
I haven't fully understood your proposal yet, so FWIW it's hard for me to say
just yet.
> 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.
I think you might find you need to work through this part in more detail. Part
of the essential trickiness in nailing down the semantics of a continuation
operator is specifying *exactly* how much of the continuation is suspended.
I don't understand the |promise| "auto-variable" you mention. What does it do?
Does it affect control flow as well, or is it no difference from (new
Promise()) for some built-in Promise constructor? (BTW, automatically-bound
variables like |arguments| are a mis-feature IMO, and I'd urge you to
reconsider that part.)
What does it mean when you say in your post that "the @ operator will wait to
continue"? What does it mean in JS to "wait?" Does it mean that evaluation of
the entire statement suspends and the result is a new promise? Where does that
promise go? Statements discard their result, more or less (notwithstanding the
completion value, which in most cases in the language really is discarded), so
how does that promise not just disappear?
You mention a ternary form but I can't find it anywhere in the blog post. Do
you describe it in any more detail somewhere else?
What is the specification of p.defer()? Does it cause its containing function
to suspend? Or just its containing statement?
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
