natively negotiating sync vs. async...without callbacks

[Getify Solutions]

>
>      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 (errorResponse) {
>             console.log("failed HTTP request: " +
> errorResponse.statusText);
>         }
>         ... foo.responseText ... bar.responseText ... baz.responseText ...
>     });
>

This style is similar to what I'm proposing, except for a few important
things:

1. 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. While I
wouldn't be strongly opposed to it, it seems a little unnatural to have to
wrap a collection of like-behaving stuff in a { }... if that were the case,
just use an anonymous function (without or without the shorter syntax) and
not have to change the meaning of { } blocks. But I can see some merit in
this concept. Just not hugely in favor of it.

2. It breaks a fundamental thing that *I* happen to think is really
important... it puts the control of whether a function is yielded or not
into the hands of the calling code. I happen to think the function call
itself should get to decide if he wants to yield asynchronously, or finish
synchronously.

For instance, imagine a function that retrieves a value from some
"database", but employs some memoization/local caching. In the first call
case, that function will need to return asynchronously. But in the cached
case, that function can and should return immediately. It'd be nice for the
function to get to decide conditionally if it wants to "yield" or "defer"
itself based on that state.

And the calling code, by virtue of something like the native operator I
suggested, can be written just one way and not care about that hidden
detail.

lookupDBValue("something") @ printValue();

For async, `printValue` will be held up from executing until `lookupDBValue`
signals that it's complete by fulfilling its promise. For sync,
`lookupDBValue` will already have its promise fulfilled at the time it
returns, so the @ can move to immediately/synchronously executing
`printValue`.

--Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101209/f86580e4/attachment.html>