The Paradox of Partial Parametricity

Andreas Rossberg rossberg at google.com
Mon May 27 07:37:03 PDT 2013


On 27 May 2013 15:30, Tom Van Cutsem <tomvc.be at gmail.com> 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


More information about the es-discuss mailing list