github at esdiscuss.org (2013-07-12T02:27:21.465Z)
On Thu, May 23, 2013 at 6:57 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Wed, May 22, 2013 at 10:19 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> > It also adds a fulfill method. Thus, it presents two interfaces to the
> user: fulfill + chain (aka unit + bind), and Q + then (aka resolve + then).
> This seems to squarely fall into the trap Mark described in his original
> post, viz.
> >
> >> The main failure mode of standards bodies is to resolve a conflict by
> adding the union of the advocated features.
>
> Certainly a common failure mode, but it's not *always* a failure mode.
> Sometimes, there really are two distinct use-cases for something, and
> you need two solutions for it. Obviously, I believe this falls into
> that bucket, but others may disagree. ^_^
>
> In this case, it's easy to demonstrate that you *can* fulfill either
> use-case starting from the other one. .chain() lets .then() be
> created in user-space in a way such that both styles of interaction
> work together. .then() lets .chain() be created in user-space by
> splitting things into "thenable promises" and "chainable promises",
> which can't interoperate without ugliness.
>
> I was gracious and
>
> > And indeed, I think the subsequent sentences ring just as true:
> >
> >> Here, this works even worse than it usually does. The coherence of
> lifting depends on the absence of autolifting, and vice versa. We need to
> make a choice.
>
> This one doesn't even make *sense* to me. "Autolifting" (aka
> conditional lifting, aka Future#resolve) is very useful for monads.
> I'm not sure where Mark gets the idea that lifting is incoherent if
> autolifting exists. I'd appreciate being corrected if I'm wrong.
>
I went into more depth on this matter in a presentation I just did at TC39.
The slide deck is at
http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Aconcurrency&media=strawman:promisesvsmonads2.pdf.
It was written to accompany a verbal explanation, which it did, but not to
be self-explanatory. I will try to find the time to explain it, but not
today. I'll be posting more on this soon. Nevertheless, I think y'all will
get something out of the slideshow prior to this explanation.
TC39 did not yet come to an official consensus. That said, the emerging
winner in the room was clearly AP3 from slide19 of the slide deck, which
Alex has revised Promise.idl to follow. It was clear from the positions in
the room that we needed both lifting and autolifting in order to achieve
consensus. In the room I was agreeable to AP3 as well. I remain so.
AP3 only does recursive unwrapping on the return side of .then. AP2, based
on your post from yesterday, does recursive unwrapping on both sides. I
stated that I prefer the AP2 style recursive unwrapping on both sides, but
the advocates for use of .fulfill (unconditional lifting) strongly favored
AP3. I will let them speak for themselves.
Even after sleeping on it, I can live happily with AP3. It is actually even
better at supporting QP style than I appreciated yesterday. In fact, for
good QP style code, it is equivalent to AP2. I am satisfied that either in
AP2 or AP3, autolifting is coherent in the presence of lifting since the
presence of lifting will be invisible to good QP style code.
As for whether lifting is coherent in the presence of autolifting in AP3, I
will let the lifting advocates speak for themselves.
We may not have made the best choice, but we didn't make sausage.
>
> (If autolifting is your only operation, then adding lifting is
> incoherent, I agree, because you've already established that it's
> impossible to have nested containers. But the reverse does not hold
> true.)
>
> > The point of my post was to demonstrate that fulfill/chain aka unit/bind
> could be built in user space *extremely simply*, thus allowing "the nascent
> monadic efforts in JS" to go off and do their own thing for a few years
> before asking to be baked into the platform. Promises, in the
> Q-plus-then-sense, have paid their dues. It's not very sporting for the
> monadic efforts to hijack the promise-standardization train, without first
> doing similar due diligence via real-world implementations and experience.
>
> As David points out, trying to paint monads as something new and
> unproven is pretty obviously silly. They've been proving themselves
> for 20+ years.
>
> ~TJ
>
--
Cheers,
--MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130524/8c1338c9/attachment.html>
On Thu, May 23, 2013 at 6:57 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote: > On Wed, May 22, 2013 at 10:19 PM, Domenic Denicola > <domenic at domenicdenicola.com> wrote: > > It also adds a fulfill method. Thus, it presents two interfaces to the > user: fulfill + chain (aka unit + bind), and Q + then (aka resolve + then). > This seems to squarely fall into the trap Mark described in his original > post, viz. > > > >> The main failure mode of standards bodies is to resolve a conflict by > adding the union of the advocated features. > > Certainly a common failure mode, but it's not *always* a failure mode. > Sometimes, there really are two distinct use-cases for something, and > you need two solutions for it. Obviously, I believe this falls into > that bucket, but others may disagree. ^_^ > > In this case, it's easy to demonstrate that you *can* fulfill either > use-case starting from the other one. .chain() lets .then() be > created in user-space in a way such that both styles of interaction > work together. .then() lets .chain() be created in user-space by > splitting things into "thenable promises" and "chainable promises", > which can't interoperate without ugliness. > > I was gracious and > > > And indeed, I think the subsequent sentences ring just as true: > > > >> Here, this works even worse than it usually does. The coherence of > lifting depends on the absence of autolifting, and vice versa. We need to > make a choice. > > This one doesn't even make *sense* to me. "Autolifting" (aka > conditional lifting, aka Future#resolve) is very useful for monads. > I'm not sure where Mark gets the idea that lifting is incoherent if > autolifting exists. I'd appreciate being corrected if I'm wrong. > I went into more depth on this matter in a presentation I just did at TC39. The slide deck is at < http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Aconcurrency&media=strawman:promisesvsmonads2.pdf>. It was written to accompany a verbal explanation, which it did, but not to be self-explanatory. I will try to find the time to explain it, but not today. I'll be posting more on this soon. Nevertheless, I think y'all will get something out of the slideshow prior to this explanation. TC39 did not yet come to an official consensus. That said, the emerging winner in the room was clearly AP3 from slide19 of the slide deck, which Alex has revised Promise.idl to follow. It was clear from the positions in the room that we needed both lifting and autolifting in order to achieve consensus. In the room I was agreeable to AP3 as well. I remain so. AP3 only does recursive unwrapping on the return side of .then. AP2, based on your post from yesterday, does recursive unwrapping on both sides. I stated that I prefer the AP2 style recursive unwrapping on both sides, but the advocates for use of .fulfill (unconditional lifting) strongly favored AP3. I will let them speak for themselves. Even after sleeping on it, I can live happily with AP3. It is actually even better at supporting QP style than I appreciated yesterday. In fact, for good QP style code, it is equivalent to AP2. I am satisfied that either in AP2 or AP3, autolifting is coherent in the presence of lifting since the presence of lifting will be invisible to good QP style code. As for whether lifting is coherent in the presence of autolifting in AP3, I will let the lifting advocates speak for themselves. We may not have made the best choice, but we didn't make sausage. > > (If autolifting is your only operation, then adding lifting is > incoherent, I agree, because you've already established that it's > impossible to have nested containers. But the reverse does not hold > true.) > > > The point of my post was to demonstrate that fulfill/chain aka unit/bind > could be built in user space *extremely simply*, thus allowing "the nascent > monadic efforts in JS" to go off and do their own thing for a few years > before asking to be baked into the platform. Promises, in the > Q-plus-then-sense, have paid their dues. It's not very sporting for the > monadic efforts to hijack the promise-standardization train, without first > doing similar due diligence via real-world implementations and experience. > > As David points out, trying to paint monads as something new and > unproven is pretty obviously silly. They've been proving themselves > for 20+ years. > > ~TJ > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130524/8c1338c9/attachment.html>