The Paradox of Partial Parametricity

Tom Van Cutsem at
Mon May 27 08:09:08 PDT 2013

2013/5/27 Andreas Rossberg <rossberg at>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list