Killing `Promise.fulfill`

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Killing `Promise.fulfill`

Domenic Denicola-2
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus following errata) I created the following promise:

```js
var foreverPending = new Promise(() => {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```

This brings up the horrible point that `Promise.fulfill(foreverPending)` creates a promise that is pending, not fulfilled. Argh!

There's also the issue that the distinction between accepted and resolved is not very useful. They are only distinguishable by flatMap, not by then, and the distinction that flatMap can make is confusing and doesn't seem to buy anything.

Tab and I think the solution to this is to:

- Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise initializer.
- Change `flatMap` to operate on resolved values, so that `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))` works.

This removes the "accepted" state entirely. It means `flatMap` effectively becomes a method for peeking into resolved promises and seeing what they are resolved to.

This also opens up the possibility of making the promise constructor go back to `new Promise((resolve, reject) => ...)`, in alignment with Promises/A+ and symmetric with `then`. The current asymmetric choice of `new Promise(({ resolve, reject, fulfill }) => ...)` has always felt unfortunate to me.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Alex Russell-4
So what? This isn't bad. It's just what happens in implementations where you don't have timeouts enforced by the system.

C'est la vie.

On Monday, August 19, 2013, Domenic Denicola wrote:
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus following errata) I created the following promise:

```js
var foreverPending = new Promise(() => {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```

This brings up the horrible point that `Promise.fulfill(foreverPending)` creates a promise that is pending, not fulfilled. Argh!

There's also the issue that the distinction between accepted and resolved is not very useful. They are only distinguishable by flatMap, not by then, and the distinction that flatMap can make is confusing and doesn't seem to buy anything.

Tab and I think the solution to this is to:

- Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise initializer.
- Change `flatMap` to operate on resolved values, so that `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))` works.

This removes the "accepted" state entirely. It means `flatMap` effectively becomes a method for peeking into resolved promises and seeing what they are resolved to.

This also opens up the possibility of making the promise constructor go back to `new Promise((resolve, reject) => ...)`, in alignment with Promises/A+ and symmetric with `then`. The current asymmetric choice of `new Promise(({ resolve, reject, fulfill }) => ...)` has always felt unfortunate to me.

_______________________________________________
es-discuss mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;es-discuss@mozilla.org&#39;)">es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Killing `Promise.fulfill`

Domenic Denicola-2
I don't really understand your response. What timeouts are you talking about? (Wrong thread perhaps?)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Killing `Promise.fulfill`

Ron Buckton-2
In reply to this post by Domenic Denicola-2
Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on the input side of Promise#then:

*then:*
```js
var foreverPending = new Promise(() => {});
Promise.fulfill(foreverPending).then(x => assert(x === foreverPending))
Promise.resolve(foreverPending).then(() => { /* never reached */ });
```

*now*
```js
var foreverPending = new Promise(() => {});
Promise.fulfill(foreverPending).flatMap(x => assert(x === foreverPending));
Promise.fulfill(foreverPending).then(() => { /* never reached */ });
```

With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

Ron


> -----Original Message-----
> From: es-discuss [mailto:[hidden email]] On Behalf Of
> Domenic Denicola
> Sent: Monday, August 19, 2013 11:13 AM
> To: [hidden email]
> Subject: Killing `Promise.fulfill`
>
> In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus
> following errata) I created the following promise:
>
> ```js
> var foreverPending = new Promise(() => {}); var acceptedButNotResolved =
> Promise.fulfill(foreverPending); ```
>
> This brings up the horrible point that `Promise.fulfill(foreverPending)` creates a
> promise that is pending, not fulfilled. Argh!
>
> There's also the issue that the distinction between accepted and resolved is not
> very useful. They are only distinguishable by flatMap, not by then, and the
> distinction that flatMap can make is confusing and doesn't seem to buy
> anything.
>
> Tab and I think the solution to this is to:
>
> - Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise
> initializer.
> - Change `flatMap` to operate on resolved values, so that
> `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))`
> works.
>
> This removes the "accepted" state entirely. It means `flatMap` effectively
> becomes a method for peeking into resolved promises and seeing what they
> are resolved to.
>
> This also opens up the possibility of making the promise constructor go back to
> `new Promise((resolve, reject) => ...)`, in alignment with Promises/A+ and
> symmetric with `then`. The current asymmetric choice of `new Promise(({
> resolve, reject, fulfill }) => ...)` has always felt unfortunate to me.
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Tab Atkins Jr.
On Mon, Aug 19, 2013 at 12:50 PM, Ron Buckton <[hidden email]> wrote:
> Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on the input side of Promise#then:

Exactly.

> With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

Yup, having unwrapping both on the value side (in the form of
Promise.resolve()) and on the read side (in the form of .then()) is
just confusing, and doesn't offer any new abilities.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Tab Atkins Jr.
In reply to this post by Domenic Denicola-2
On Mon, Aug 19, 2013 at 11:13 AM, Domenic Denicola
<[hidden email]> wrote:
> Tab and I think the solution to this is to:
>
> - Kill `Promise.fulfill`, and of course also the `fulfill` option to the promise initializer.
> - Change `flatMap` to operate on resolved values, so that `Promise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))` works.

Note that both of these are just name changes, not functionality
changes.  (Killing the old Promise.resolve() semantics is a
functionality change, but not these two.)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Kevin Smith
In reply to this post by Ron Buckton-2

With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

I tend to agree.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2
Let's separate two forms of complexity:

a) Complexity visible to those who must use, implement, or understand the full API including .flatMap.

b) Complexity visible to those who only use, implement, or understand the subset without .flatMap.

The main beauty of AP2 is that it minimizes the complexity of #b. My hypothesis and hope is that #b has the same complexity as a Promises/A+ compatible promise proposal would be without flatMap. If adding flatMap support increases the complexity of #b, that would be bad. Do you see any way in which it does?

Note that #b differs from "a Promises/A+ compatible promise proposal would be without flatMap" in one substantive way: Moving the recursive unwrapping/flattening/assimilation to the input side of .then. As already discussed on the Promises/A+ list, this should be close to compatible with Promises/A+ code, as the difference is only visible when the behavior of recursive unwrapping is side-effect-dependent. Also, it should make things simpler, as the "resolve" operation (or whatever it would be called) would no longer need to do the recursive unwrapping. By putting recursive unwrapping on the input side of .then, it need not appear anywhere else.

Assuming TC39 declares consensus on AP2, I expect Promises/A+ to move the recursive unwrapping to the .then input, or to at least allow it, so that TC39 and DOM promises remain compatible with Promises/A+. Likewise with Q. I don't expect either Promises/A+ or Q to ever provide .flatMap.

I leave it to the DOM folks to evaluate whether the subset they need soon needs to include .flatMap.




On Mon, Aug 19, 2013 at 5:11 PM, Kevin Smith <[hidden email]> wrote:

With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

I tend to agree.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2



On Mon, Aug 19, 2013 at 6:20 PM, Mark S. Miller <[hidden email]> wrote:
Let's separate two forms of complexity:

a) Complexity visible to those who must use, implement, or understand the full API including .flatMap.

b) Complexity visible to those who only use, implement, or understand the subset without .flatMap.

The main beauty of AP2 is that it minimizes the complexity of #b. My hypothesis and hope is that #b has the same complexity as a Promises/A+ compatible promise proposal would be without flatMap. If adding flatMap support increases the complexity of #b, that would be bad. Do you see any way in which it does?

Note that #b differs from "a Promises/A+ compatible promise proposal would be without flatMap" in one substantive way: Moving the recursive unwrapping/flattening/assimilation to the input side of .then. As already discussed on the Promises/A+ list, this should be close to compatible with Promises/A+ code, as the difference is only visible when the behavior of recursive unwrapping is side-effect-dependent. Also, it should make things simpler, as the "resolve" operation (or whatever it would be called) would no longer need to do the recursive unwrapping. By putting recursive unwrapping on the input side of .then, it need not appear anywhere else.

To clarify, the status quo is that recursive unwrapping happens on both the output side of .then and in Promise.resolve. Moving it to the input side of .then is exactly as useful, is almost exactly compatible, and does the complicated thing in one place rather than two. Even without adding .flatMap, this is a good idea anyway.

 

Assuming TC39 declares consensus on AP2, I expect Promises/A+ to move the recursive unwrapping to the .then input, or to at least allow it, so that TC39 and DOM promises remain compatible with Promises/A+. Likewise with Q. I don't expect either Promises/A+ or Q to ever provide .flatMap.

I leave it to the DOM folks to evaluate whether the subset they need soon needs to include .flatMap.




On Mon, Aug 19, 2013 at 5:11 PM, Kevin Smith <[hidden email]> wrote:

With all the changes to Promise (addition of Promise#flatMap, recursive unwrap on input side of Promise#then, etc.), it does seem that fulfill's use case has become a bit muddled. I'll admit to still being partial to the earlier design (fulfill/resolve/reject, adopt without recursive unwrap/flattening) as it was a much simpler and more straightforward API.

I tend to agree.

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Killing `Promise.fulfill`

Domenic Denicola-2
In reply to this post by Mark S. Miller-2
Mark, I completely agree with you. However, I think this somewhat ignores the issue of this thread. The problem with AP2, even completely ignoring `flatMap`, comes when you consider the behavior of the `Promise.fulfill` method. Namely, what does this code do?

```js
var foreverPending = new Promise(() => {});
var p = Promise.fulfill(foreverPending);
```

Because the recursive unwrapping has moved to the `then` side, we have that

```js
p.then(() => console.log("this will never be called"));
```

Such a promise `p` *cannot* be called fulfilled, if its fulfillment handler will never be called. From existing Promises/A+ definitions, it is resolved, but pending. Yet it was returned by `Promise.fulfill`, making that method a lie.

One could answer by saying that you should ignore `Promise.fulfill` (and the resolver's `fulfill` callback), and this would be justifiable. Indeed, just like `flatMap`, I expect `fulfill` to be ignored by Promises/A+ and the broader community of promise users. But it prevents a severe pedagogical difficulty, because on the one hand, we are telling people that the fundamental states of a promise are fulfilled, rejected, and pending, whereas on the other hand we are saying that `Promise.fulfill` is a broken, mis-named method that should never be used even if you want to produce a fulfilled promise. (Or rather, especially not then!)

As to your message, I guess it is unclear to me whether you envision `Promise.fulfill` as part of the eventual TC39 consensus. Even if you don't, as of now it's part of the DOM folks design, and I was hoping to stop a mistake there as well.
 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2
I agree that an AP2 system, which is what we are discussing, should not have a method named .fulfill for the reasons you state. A promise which, at the AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level "resolved". I suggest the method in question be called .resolve, that it accept, not recursively unwrap/flatten/assimilate at all. The AP2.flatMap programmer will understand .resolve as accepting. The AP2.then programmer will understand .resolve as resolving.


On Mon, Aug 19, 2013 at 6:34 PM, Domenic Denicola <[hidden email]> wrote:
Mark, I completely agree with you. However, I think this somewhat ignores the issue of this thread. The problem with AP2, even completely ignoring `flatMap`, comes when you consider the behavior of the `Promise.fulfill` method. Namely, what does this code do?

```js
var foreverPending = new Promise(() => {});
var p = Promise.fulfill(foreverPending);
```

Because the recursive unwrapping has moved to the `then` side, we have that

```js
p.then(() => console.log("this will never be called"));
```

Such a promise `p` *cannot* be called fulfilled, if its fulfillment handler will never be called. From existing Promises/A+ definitions, it is resolved, but pending. Yet it was returned by `Promise.fulfill`, making that method a lie.

One could answer by saying that you should ignore `Promise.fulfill` (and the resolver's `fulfill` callback), and this would be justifiable. Indeed, just like `flatMap`, I expect `fulfill` to be ignored by Promises/A+ and the broader community of promise users. But it prevents a severe pedagogical difficulty, because on the one hand, we are telling people that the fundamental states of a promise are fulfilled, rejected, and pending, whereas on the other hand we are saying that `Promise.fulfill` is a broken, mis-named method that should never be used even if you want to produce a fulfilled promise. (Or rather, especially not then!)

As to your message, I guess it is unclear to me whether you envision `Promise.fulfill` as part of the eventual TC39 consensus. Even if you don't, as of now it's part of the DOM folks design, and I was hoping to stop a mistake there as well.




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Kevin Smith
In reply to this post by Mark S. Miller-2
Thanks Mark.

To clarify my overly brief interjection, I tend to favor the conceptual simplicity of the earlier "DOM" API.  Specifically:

- no "flatMap"
- the output of then is single-unwrapped
- no recursive unwrapping

I find it more simple from a conceptual standpoint because each promise simply resolves to some value (possibly a promise) which can be accessed via then.

If I remember correctly, AP2 was motivated by the need to support both recursive unrwapping and single-unwrapping with a single API.  It is a clever solution, to be sure.  But can we not simply provide a recursive unwrapping helper function?

    Promise.when(unknown).then(unwrapped => console.log(unwrapped));

In this case, `unwrapped` will be the result of recursively unwrapping `unknown`, if `unknown` is a promise, and the value `unknown` otherwise.

{ Kevin }



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Kevin Smith
Implementation:

    function unwrap(value) {
        return Promise.resolve(value).then(v => isPromise(v) ? unwrap(v) : v);
    }

    Promise.when = value => unwrap(value);

Test:

    var promise = new Promise(r => {
        r.fulfill(new Promise(r => { r.fulfill(1); }));
    });

    promise.then(val => console.log(val.then ? "promise" : "value"));
    Promise.when(promise).then(val => console.log(val.then ? "promise" : "value"));

    >> promise
    >> value

{ Kevin }


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2
In reply to this post by Kevin Smith
Hi Kevin, I misinterpreted you. By "earlier", I thought you were referring to the promise APIs in actual use which are compatible with Promises/A+. These do not create promises-for-promises (auto-flattening or auto-lifting depending on how you want to think about it) and they recursively unwrap thenables (assimilation). The first, auto-flattening/auto-lifting, is a requirement for the .then-oriented promise patterns in use, as has been discussed exhaustively here and on Promises/A+. The second, assimilation, is an unfortunate but expedient hack that enables multiple promise libraries to co-exist. The origin of the modern JS promises is the promise system of the E language which had auto-flattening/auto-lifting but no assimilation, since co-existence was not an issue.

The "earlier" you are talking about, IIUC, is the monadic promise variant. Monads are fine things, and a monadic promise=like abstraction would probably be useful for some things. However, it is a very different abstraction and it does not support the .then oriented patterns that JS promises are used with. I think we would be better off omitting these from standard promises, but we cannot get quick consensus on a promise system which omits them. Without a quick consensus, DOM will do something else. Fortunately, AP2 allows these to live together in one API more painlessly than I had thought possible.



On Mon, Aug 19, 2013 at 7:17 PM, Kevin Smith <[hidden email]> wrote:
Thanks Mark.

To clarify my overly brief interjection, I tend to favor the conceptual simplicity of the earlier "DOM" API.  Specifically:

- no "flatMap"
- the output of then is single-unwrapped
- no recursive unwrapping

I find it more simple from a conceptual standpoint because each promise simply resolves to some value (possibly a promise) which can be accessed via then.

If I remember correctly, AP2 was motivated by the need to support both recursive unrwapping and single-unwrapping with a single API.  It is a clever solution, to be sure.  But can we not simply provide a recursive unwrapping helper function?

    Promise.when(unknown).then(unwrapped => console.log(unwrapped));

In this case, `unwrapped` will be the result of recursively unwrapping `unknown`, if `unknown` is a promise, and the value `unknown` otherwise.

{ Kevin }





--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2
In reply to this post by Kevin Smith
How does what you mean by .then here differ from .flatMap? If it is the same, why not rename your .then to .flatMap and rename your .when to .then ?


On Mon, Aug 19, 2013 at 8:14 PM, Kevin Smith <[hidden email]> wrote:
Implementation:

    function unwrap(value) {
        return Promise.resolve(value).then(v => isPromise(v) ? unwrap(v) : v);
    }

    Promise.when = value => unwrap(value);

Test:

    var promise = new Promise(r => {
        r.fulfill(new Promise(r => { r.fulfill(1); }));
    });

    promise.then(val => console.log(val.then ? "promise" : "value"));
    Promise.when(promise).then(val => console.log(val.then ? "promise" : "value"));

    >> promise
    >> value

{ Kevin }




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Kevin Smith
In reply to this post by Mark S. Miller-2

The "earlier" you are talking about, IIUC, is the monadic promise variant.

I don't like using the term "monadic" because it sounds pointy-headed : )
 
Monads are fine things, and a monadic promise=like abstraction would probably be useful for some things. However, it is a very different abstraction and it does not support the .then oriented patterns that JS promises are used with.

I question this assertion.

A general promise:  P0<P...<Pn<V>>>

Yes - Q does perform recursive unwrapping of the callback return value.  But Q provides no "fulfill" equivalent.  There is absolutely no way to create a Q promise where n > 0.  The only way to observe Q's recursive unwrapping behavior is by handing it a foreign promise where n > 0.  That case (as far as I know) is rare.

Essentially then, Q lives in a universe where n = 0 for all P.  The "then" usage patterns are therefore agnostic with respect to recursive unwrapping.

I think perhaps the correct place for recursive unwrapping is a helper function (perhaps "when") defined on the Promise constructor.  This function would normalize any input to a promise where n = 0.  I argue that this is what is wanted for the AsyncTable use case.

    class AsyncTable<t,u> {

        constructor() {
            this.m = Map<t,u>();
        }
    
        set(keyP :Ref<t>, val :Ref<u>) {
            Promise.when(keyP).then(key => { this.m.set(key, val) });
        }
    
        get(keyP :Ref<t>) :Promise<u> {
            return Promise.when(keyP).then(key => this.m.get(key));
        }
    }

Note that I've simply replaced "Q" with "Promise.when" from your original example.  We are basically just coercing an arbitrary type to P0<V>.  We will always want to use this kind of coersion when accepting arbitrary input and need an n = 0 promise.

{ Kevin }

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Anne van Kesteren
In reply to this post by Mark S. Miller-2
On Tue, Aug 20, 2013 at 2:48 AM, Mark S. Miller <[hidden email]> wrote:
> I agree that an AP2 system, which is what we are discussing, should not have
> a method named .fulfill for the reasons you state. A promise which, at the
> AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level
> "resolved". I suggest the method in question be called .resolve, that it
> accept, not recursively unwrap/flatten/assimilate at all. The AP2.flatMap
> programmer will understand .resolve as accepting. The AP2.then programmer
> will understand .resolve as resolving.

I remembered we previously reached this conclusion and then you ended
up reversing yourself:
http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0213.html Did
something change or am I misinterpreting something?

(I'm in favor of removing fulfill() myself, for what it's worth.)


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Mark S. Miller-2
Hi Anne, Thanks for the reminder. My message of last night fell into that same old trap (ignoring the storage cost) and that previous reversal of mine is still mostly correct, However, the missing operation is not .fulfill for the reasons Domenic correctly explains. It is .accept (possibly named .of) because it observably differs from .resolve only to .flatMap observers; whereas the distinction between "pending", "fulfilled" and "rejected" is observable to .then observers.


On Tue, Aug 20, 2013 at 7:02 AM, Anne van Kesteren <[hidden email]> wrote:
On Tue, Aug 20, 2013 at 2:48 AM, Mark S. Miller <[hidden email]> wrote:
> I agree that an AP2 system, which is what we are discussing, should not have
> a method named .fulfill for the reasons you state. A promise which, at the
> AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level
> "resolved". I suggest the method in question be called .resolve, that it
> accept, not recursively unwrap/flatten/assimilate at all. The AP2.flatMap
> programmer will understand .resolve as accepting. The AP2.then programmer
> will understand .resolve as resolving.

I remembered we previously reached this conclusion and then you ended
up reversing yourself:
http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0213.html Did
something change or am I misinterpreting something?

(I'm in favor of removing fulfill() myself, for what it's worth.)


--
http://annevankesteren.nl/



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Killing `Promise.fulfill`

Anne van Kesteren
On Tue, Aug 20, 2013 at 3:08 PM, Mark S. Miller <[hidden email]> wrote:
> Hi Anne, Thanks for the reminder. My message of last night fell into that
> same old trap (ignoring the storage cost) and that previous reversal of mine
> is still mostly correct, However, the missing operation is not .fulfill for
> the reasons Domenic correctly explains. It is .accept (possibly named .of)
> because it observably differs from .resolve only to .flatMap observers;
> whereas the distinction between "pending", "fulfilled" and "rejected" is
> observable to .then observers.

Okay. I think what I'm interested in for the DOM for now is nailing
down the details of the subset that excludes accept/flatMap. Those can
be added in ES7.

In particular, what *kind* of unwrapping does then() do on the input
and return side (ideally expressed in pseudo-code). And what's the
state of a promise that's .resolve()'d with a promise-like or a
promise? "pending" I guess?


--
http://annevankesteren.nl/
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Killing `Promise.fulfill`

Domenic Denicola-2
In reply to this post by Mark S. Miller-2
Indeed, nice catch Anne. I guess it's an unfortunate necessity that the monadic stuff will need to drag along two methods, not just one.

A name like "unit" (or perhaps "of") seems to fit better in my mind, than introducing another natural-language verb like "accept." Especially since it will be used alongside "flatMap," and ignored by "then" users.

At this point I'd like to have a moment of silence for our treasured and dearly departed friend, "separation of concerns."
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123