The Paradox of Partial Parametricity

Sam Tobin-Hochstadt samth at ccs.neu.edu
Sat May 25 06:29:06 PDT 2013


On Fri, May 24, 2013 at 1:42 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>
> AP3 (recursive unwrapping of the return value of .then()) doesn't give
> Q people the guarantees they want (.then() callbacks always receive a
> plain value), nor does it give monadic people the flexibility they
> want (Domenic's proposal is, I'm sorry, abhorrent in its details -
> I'll provide more reasoning at the end of this email).  It also adds a
> *useless* fulfill method - you can't actually *use* the fact that the
> promises are nested at all, which is just plain silly.  AP3 is
> straight-up consensus-exhaustion, where people weren't thinking the
> details through sufficiently to realize the details weren't coherent.

Since the minutes aren't available yet (thanks to Arv for working on
that), I'll say a little about what happened in the meeting. As the
person who spoke out the most, I think, for the proposals that
unfortunately go under the "monadic" rubric, my #1 concern is that
promises can be used to build compositional APIs.  This means API like
a future async-local-storage where no restriction on the domain of
values to "non-promises" is required for the API to work correctly. I
think is significantly more important than whether the promise API is
monadic in the sense you've advocated for, although I'd certainly like
that too.

In the meeting, there were (a) people advocating for styles of
programming along the lines that you (Tab) have put forward, like me,
(b) people advocating for Q-style programming, like Mark, Yehuda, and
Tom, and (c) genuine concern about the complexity budget of the
promise API, expressed most by Luke Hoban, but felt by all of us. Were
it not for this last concern, I think AP2 would have seemed more
attractive.  But since the set of methods available on Promises
themselves is the most visible part of the API, and AP2 doubles its
size, that told heavily against AP2. Given that, my personal
preference would have been for an API that never did recursive
unwrapping, but given the wide existing precedent for .then() doing
multiple levels of unwrapping, it seems like that semantics would
require a second method on all promises.

This line of reasoning led everyone in the room to the point that Mark
reported. This isn't the point that anyone would have chosen from
first principles, but I do think that as Mark says, it allows everyone
to get most of what they want without falling into a union-of-features
result.

Sam


More information about the es-discuss mailing list