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.

(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

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.

(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.