The Paradox of Partial Parametricity
Mark S. Miller
erights at google.com
Fri May 10 14:04:37 PDT 2013
[dropping public-script-coord. Let's keep the discussion on es-discuss.
Apologies again on starting this thread with an email to the wrong list.]
On Fri, May 10, 2013 at 1:00 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> [Forgot to pick up es-discuss in this message. >_<]
> On Fri, May 10, 2013 at 11:42 AM, Tab Atkins Jr. <jackalmage at gmail.com>
> > On Fri, May 10, 2013 at 5:52 AM, Mark S. Miller <erights at google.com>
> >> Together with each of their explanations about what they meant. They are
> >> both right. Lifting and auto-lifting do not mix. Q Promises give us
> >> autolifting with no lifting. Monadic promises would give us lifting but
> >> autolifting. Having both in one system creates a mess which will lead
> >> programmers into the particular pattern of bugs Jonas warns about in his
> >> message.
> I have no idea why you're trying to claim that "monadic promises"
> > gives no auto-lifting. Perhaps you've gotten yourself confused over
> > the proposals, and have reverted to a particularly strict view of what
> > "monadic promises" means?
> > The proposal called "monadic promises" implies nothing more than that,
> > if the value returned by a .then() callback is a promise, one level of
> > unwrapping will occur. If you purposely return a nested promise, we
> > won't strip out *all* the levels, only the outermost.
> >> * A Monadic promise system would have Q.fulfill, p.map, and p.flatMap.
> >> * A Q-like promise system would have Q, and p.then
> >> * The dominant non-Q-like proposal being debated in these threads has
> >> Q.fulfill, Q, and p.then.
> The "unabashed monadic" version is more predictable for generic code,
> > but less convenient for normal code (you have to be sure of whether
> > your return value is a plain value or a promise, while .then() lets
> > you ignore that for the most part).
> > The Q version (auto-flattening all the time, no nested promises) is
> > predictable both ways, but at the cost of erasing an entire class of
> > use-cases where you want to be able to interact with a promise
> > reliably without regard to what's inside of it.
Hi Tab, I did not intend to start a fight with you over the term "monadic
promises". Since we seem to be otherwise in agreement on the three
architectures to be compared as well as many of the implications of each,
I'm happy to call the first bullet above "unabashed monadic promises", the
second "Q-like promises" and the third "abashed monadic promises". Is this
acceptable? If not, please suggest something you expect we can all find
acceptable. AFAICT, this is the last terminology battle that still
distracts us from semantics.
One request: If you do suggest alternate terminology, don't call #3
"monadic promises" while at the same time calling #1 "<adjective> monadic
promises". That would make #1 seem like a subtype of #3. Either prefix both
with an adjective or make them otherwise distinct.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss