Subject: Re: Harmony - proxies | asynchronous

[John J Barton]

On Sun, Sep 4, 2011 at 1:42 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Sep 4, 2011, at 11:06 AM, John J Barton wrote:
>
> 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".
>
>
> This is addressed in ES6 by changing the head of the generator function as
> follows:
>
> 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);
>     }
> });
>
>  (For others who have some trouble seeing the difference, here the function
keyword is followed by the multiplication symbol).

"generator() {}" would make a lot more since to me, it would more clearly
alert the reader at no added cost for the writer, as well as helping new
users of this feature separate it's effect from functions.

>
>
> 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().
>
>
> No, you can use spawn as a black box. It's an API entry point to the taskjs
> library. You do not need to read the source to use an API.
>

Hmm., the doc http://dherman.github.com/taskjs/doc/api.html says:
  Task spawn(generator function thunk)
But as I understand it, the send() plays a role in the API to spawn correct?


>
> 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.
>
>
> There's no free lunch. Either we renounce adding new syntax by which to
> capture a shallow continuation, which leaves us with the nested callback
> function world of today, which people object to on several grounds:
>
> * Nesting makes hard-to-read, rightward-drifting function spaghetti.
>
> * Nesting increases the risk of capturing too much environment, potentially
> entraining memory for a long time -- bloat and leak bugs.
>
> These are not unmanageable according to some JS hackers, but they are not
> trivial problems either. They keep coming up, in the Node community and
> among browser JS developers. They're real.
>

So it is known that no alternative exists beyond these two choices?
jjb

>
> 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.
>
>
> Right.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110905/c0986e43/attachment.html>