Subject: Re: Harmony - proxies | asynchronous

[John J Barton]

On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Sep 5, 2011, at 9:36 PM, John J Barton wrote:
> ...
>
> 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?
>
>
> On this list, we have been over the design space many times. Please search
> for call/cc and "shallow continuations" using site:mail.mozilla.org. I'm
> short on time now.
>
> The upshot is that you're suggesting threads, or deep continuations.
> Threads suck, we are not exposing JS developers to preemptively scheduled
> threads in a language with shared-object mutation and therefore significant
> data races.
>

Thanks, but as you told me: 'I did not say that. Remember,
t<http://brendaneich.com/2007/02/threads-suck/>hreads
suck'.  I was more thinking along the lines of better support for async
programming that does not attempt to look sync (I have no idea what that
means).


>
> Deep continuations have two problems:
>
> 1. They break the ability to reason about loss of invariants due to an
> event loop turn being taken under what looks like a function call.
>
> 2. The second problem is that different implementations will not agree on
> capturing deep continuations across native frames, but interoperation
> demands one standards. Forbidding capture across native frames breaks
> abstraction over self-hosted vs. native code (e.g. Array map calling its
> downward funarg). Requiring will mean that some VMs won't be able to conform
> to such a spec -- Java, .NET, any without hand-coded magic to deal with
> compiler magic involving native frame representation.
>
> This leaves shallow continuations, and generators won out in a fair fight
> with a more minimal "shift" proposal for shallow continuations (too
> minimal).
>
> Generators share with private name objects a right-sized (minimal but not
> too small) gap-filling quality that supports all of:
>
> * prompt standardization,
> * interoperable implementation, and
> * library ecosystem builder upside far beyond what TC39 could ever do on
> any schedule.
>
> They're in ES6 for good reason.
>

Unfortunately we are comparing a tiny number of generator programs written
by experts to a unknown fraction of callback programs written by
right-marching developers.  I think developers will be slow to take up
generators, but on the other hand it's an important problem and one worth
taking risks to explore.

jjb


>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110906/e8a84d46/attachment.html>