On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich <[email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
