natively negotiating sync vs. async...without callbacks

[David Herman]

> 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