2013/5/27 Andreas Rossberg <[email protected]> > On 27 May 2013 15:30, Tom Van Cutsem <[email protected]> wrote: > > What the discussion at last week's TC39 meeting clarified for me is the > > following: > > > > - Promises are primarily a control-flow abstraction. > > - Sometimes, they are also used as a data-abstraction (i.e. as a > container > > in their own right, wrapping an arbitrary payload). > > - All of the subtle problems discussed in these threads only start to > arise > > when these two use cases of promises are being mixed, e.g. a > > promise-as-data-container being mistaken for a > > promise-as-control-abstraction. This rarely happens in application code, > but > > may happen in generic library code. > > Well, the gist of higher-order languages is that control flow > abstractions _are_ data. For example, that's the defining > characteristics of first-class functions. And while most functions > won't be used in a first-class manner (and most programmers probably > don't think about them that way), the ability to do so gives great > power -- as JavaScript demonstrates very well. > > Futures/promises are an abstraction for first-class synchronisation. > For the same reason you sometimes want to store or pass back & forth > functions, you will sometimes want to store or pass promises. Not > being able to combine those abstractions freely and transparently > would arbitrarily limit their power, and practically demote promises > to second-class status. >
I agree with everything you said, but I fail to see why Q-style promises would become second-class. I have enjoyed writing and working with higher-order combinators like Q.all, which creates a promise for an array of promises. Your text above would seem to imply that writing or using such combinators would somehow be hampered by the recursive flattening, but I have never bumped into this issue. I think the reason is that when promises are used as data in combinators like Q.all, the composite abstraction as a whole remains a control-flow abstraction. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
