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. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
