Subject: Re: Harmony - proxies | asynchronous

[John J Barton]

On Fri, Sep 2, 2011 at 4:39 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Sep 2, 2011, at 4:15 PM, John J Barton wrote:
>
> Ok I hope someone creates more tutorial information about generators. I
>> read about them and played around with some examples, but I did not come
>> away thinking positive.
>>
>
> You might start with Dave Herman's async library, task.js:
>
> https://github.com/dherman/taskjs/
>

The example on that page illustrates my concerns:

spawn(function() {
    try {
        var [foo, bar] = yield join(read("foo.json"),
                                    read("bar.json")).timeout(1000);
        render(foo);
        render(bar);
    } catch (e) {
        console.log("read failed: " + e);
    }
});

As far as I understand it, the function passed as an argument to spawn()
will be called by spawn(), but it will not execute and spawn() will not
receive its return value. Instead, spawn() will get an object with a next()
function.

When spawn() calls the next() function, then the function we are read above
executes up the the 'yield' keyword; the expression which follows 'yield' is
evaluated and returned as the value of the next() function.

When spawn() calls the next() function a second time, the function we read
above executes differently. We don't start at the beginning, but after the
expression following yield.

As a reader I have to parse the function carefully to look for the 'yield'.
If I find one, then I know that this is not actually a function after all.
Then I need to mentally draw a line after the yield and label it
"entry-point #2".

Next I have to read through the source of spawn() and track the lifetime-of
and references-to the object it received, seeking calls to send(). When I
find them, the argument will be the result of the yield operation above.
Hopefully the next() call will be textually near to the send() call so I can
work out which send() matches which yield.

Assuming I am understanding the idea, then my description above is also my
criticism: control and data flow is jumping around in unusual ways and
functions morph into multi-entry point things with new API.

On the positive side I can now see the advantage of this approach.  The I/O
request and action on its response are now neatly separated from the
spaghetti. I can study and curse at the yield/next/send code, but once I
have made that investment the source and sink of foo and bar are clearly
related. The funky stuff is in infrastructure not (mostly) in application
code.

jjb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110904/f3b89457/attachment-0001.html>