Subject: Re: Harmony - proxies | asynchronous

John J Barton johnjbarton at
Tue Sep 6 09:37:04 PDT 2011

On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich <brendan at> 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 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,
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

> 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.


> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list