On Tue, Sep 6, 2011 at 12:37 PM, John J Barton <johnjbar...@johnjbarton.com>wrote:
> > > On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich <bren...@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). > I'm also curious what "better support for async programming" looks like -- that always seem to boil down to a `wait` construct -- which it's already been established is not enabled by harmony generators. So AFAICT they do exactly what you're asking -- provide language level support for libraries to take async control flow in new directions, all without shared state, spooky action at a distance, or attempting to "look sync" :) > >> 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. > Indeed. Uptake could be aided by harmony transpilers -- traceur has generator support already (no harmony generators as yet, but in due time). Time will tell how the market moves, but like with anything else, much of the heavy lifting will happen at the library level, and Dave's Tasks are just a whiff of what's possible. The yield* construct opens the door to async iteration idioms that will put old es5 alternatives to shame. Who knows, perhaps their perceived complexity will prove too great for generators to ever go mainstream. Even if that were the case they're still a useful and practical addition our syntax toolkit.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
