Killing `Promise.fulfill`
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.
I don't really understand your response. What timeouts are you talking about? (Wrong thread perhaps?)
Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on the input side of Promise#then:
then:
var foreverPending = new Promise(() => {});
Promise.fulfill(foreverPending).then(x => assert(x === foreverPending))
Promise.resolve(foreverPending).then(() => { /* never reached */ });
now
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
On Mon, Aug 19, 2013 at 12:50 PM, Ron Buckton <rbuckton at chronicles.org> 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.
On Mon, Aug 19, 2013 at 11:13 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
Tab and I think the solution to this is to:
- Kill
Promise.fulfill, and of course also thefulfilloption to the promise initializer.- Change
flatMapto operate on resolved values, so thatPromise.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.)
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.
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 6:20 PM, Mark S. Miller <erights at google.com> 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.
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?
var foreverPending = new Promise(() => {});
var p = Promise.fulfill(foreverPending);
Because the recursive unwrapping has moved to the then side, we have that
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.
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.
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.
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
>> valueI 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.
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 ?
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.
On Tue, Aug 20, 2013 at 2:48 AM, Mark S. Miller <erights at google.com> 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: 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.)
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 3:08 PM, Mark S. Miller <erights at google.com> 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?
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."
From: annevankesteren at gmail.com
In particular, what kind of unwrapping does then() do on the input and return side (ideally expressed in pseudo-code).
I believe this comes down to the as-yet-unresolved conversation about thenable assimilation vs. branding and such. In any case, it should be recursive, if that helps.
And what's the state of a promise that's .resolve()'d with a promise-like or a promise? "pending" I guess?
It depends on the state of the promise, or the behavior of a promise-like. Resolving P with a pending promise makes P pending; resolving P with a fulfilled promise makes P fulfilled; resolving P with a rejected promise makes P rejected. The behavior for thenables is similar but of course involves more trickery to defend against e.g. throws or multiple calls.
However, note that "state" is an emergent concept in the delayed-unwrapping paradigm. It's not really something you can divine inherently, at least, not if thenables are involved. Speaking somewhat imprecisely, p is fulfilled if p.then(f, r) will call f as soon as possible; it is rejected if p.then(f, r) will call r as soon as possible; and it is pending if p.then(f, r) will call neither f nor r within an even loop turn.
If you deal only with promises, where the implementation can synchronously inspect the internal state of the promise, then you can make a guaranteed-accurate determination of which of these will happen (i.e., if P is resolved to Q, P's state is equal to Q's state; continue recursively until you reach a promise that is not resolved to another promise). But since thenables do not allow such synchronous inspection, if they are included in the model then codifying state accurately is not possible, and it would be best to leave state as an implicit concept and not try to include it in a formal specification.
On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller <erights at google.com> 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.
I have no idea what happened in this thread, because people keep referring to "the earlier X" where by "earlier" they mean "in another unnamed thread, days/weeks ago" rather than just enumerating what they're talking about. (This kind of thing is acceptable while the other threads are ongoing in parallel; it's not when the threads have been paged out of people's heads.)
But in this paragraph, specifically, what are you talking about, Mark? What is this "missing operation", who needs it, and why?
From what I understood talking to Domenic, here's what we needed:
-
Promise.resolve() and Promise.reject(). These just take a value and wrap it in a Promise, putting it on the success or failure track.
-
Promise#then() and Promise#flatMap(). flatMap waits for pending promises to become resolved or rejected, and calls its callbacks accordingly; then() waits for pending or resolved promises to become fulfilled or rejected, and calls its callbacks accordingly.
-
The resolved value of a promise (what's passed to the success callback of flatMap()) is simply the value in the promise. The fulfilled value of a promise (what's passed to the success callback of then()) depends on what's inside the promise: if it's a plain value, that's the fulfilled value; if it's a promise, its that promise's fulfilled value.
Do you think we need anything else? If so, why, and for what purpose?
(Note that if anyone thinks we need something that eagerly flattens a promise, rather than flattening happening implicitly via the definition of "fulfilled value" for then(), realize that this eager flattening operation is hostile to lazy promises. While this might be useful in some cases, it's probably not something we need or want in the core language, or if we do, it should be given an appropriately descriptive name, rather than yet another synonym for "accept".)
On Tue, Aug 20, 2013 at 8:32 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller <erights at google.com> 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.
I have no idea what happened in this thread, because people keep referring to "the earlier X" where by "earlier" they mean "in another unnamed thread, days/weeks ago" rather than just enumerating what they're talking about. (This kind of thing is acceptable while the other threads are ongoing in parallel; it's not when the threads have been paged out of people's heads.)
But in this paragraph, specifically, what are you talking about, Mark?
See lists.w3.org/Archives/Public/www-dom/2013AprJun/0213.html,
which is the message Anne links to in the message I'm immediately replying to.
But yes, I agree that we've all been using terms like "earlier" too loosely, where we should be more explicit about context.
What is this "missing operation",
.accept
who needs it, and why?
To answer this precisely, we need good terminology to distinguish two levels of abstraction: The distinctions observable to the AP2.flatMap programmer and the coarser distinctions observable to the AP2.then programmer. Let's start ignoring thenables and considering only promises-vs-non-promises. Let's also start by ignoring rejection.
At the AP2.flatMap level,
- for a promise p and an arbitrary value v, p may accept v. p is then in the "accepted" state.
- for a promise p and a promise q, p may adopt q. p is then in the "adopting" state. Putting these together, we can also say
- for a promise p and an arbitrary value v, p is resolved to v if p either accepts v or adopts v. p is then in the "resolved" state.
p2 = p1.flatMap(v1 => q2)
means, if p1 is accepted, then v1 will be what it has accepted.
If q2 is a promise, then p2 adopts q2.
p2.flatMap(...) fires as a result of acceptance but not adoption. If q2 accepts, then p2 likewise accepts and p2.flatMap fires by virtue of this acceptance.
At the P2.then level
- for a promise p and a non-promise v, p may be fulfilled with v. p is then in the fulfulled state.
- for a promise p and a promise q, p may follow q. p is then in the following state.
- Until a promise p is either fulfilled or rejected, it is pending. Putting these together, we can also say
- for a promise p and an arbitrary value v, p is resolved to v if either p is fulfilled with v or p follows v. p is then in the "resolved" state.
p4 = p3.then(v3 => v4)
means, if p3 is fulfilled, then v3 will be what p3 is fulfilled with.
p4 is resolved to v4. If v4 is a promise, then p4 follows v4. Else p4 is fulfilled with v4.
p4.then fires as a result of fulfillment but not following. If p4 follows v4 and v4 fulfills, then p4 likewise fulfills and p4.then fires by virtue of this fulfillment.
Notice that "resolved" is the same states at each level, even though these states are described differently. That is why we can use the same term at both levels. Likewise, the concept of "unresolved" is meaningful at both levels.
From what I understood talking to Domenic, here's what we needed:
- Promise.resolve() and Promise.reject(). These just take a value and wrap it in a Promise, putting it on the success or failure track.
I'm totally confused by your description of reject, but let's leave it aside for now as I have above.
I'm not so much concerned with the static .resolve method, since the extra storage cost for the static method is negligible. However, what does aResolve.resolve do? If it causes its promise to accept, this must be observably different to .flatMap observers than if it causes its promise to adopt. This difference is not observable to .then observers, which is why I've accidentally missed this issue twice now. But since an implementation cannot know ahead of time whether there might be .flatMap observers, using .accept for .resolve would impose prohibitive storage costs on .then oriented patterns. See the message Anne linked to.
- Promise#then() and Promise#flatMap(). flatMap waits for pending promises to become resolved or rejected,
If p adopts q and q is unresolved, then p is resolved but p.flatMap does not fire.
and calls its callbacks accordingly; then() waits for pending or resolved promises to become fulfilled or rejected, and calls its callbacks accordingly.
- The resolved value of a promise (what's passed to the success callback of flatMap()) is simply the value in the promise.
True for acceptance, not for adoption.
The fulfilled value of a promise (what's passed to the success callback of then()) depends on what's inside the promise: if it's a plain value, that's the fulfilled value; if it's a promise, its that promise's fulfilled value.
Do you think we need anything else? If so, why, and for what purpose?
Only to avoid the prohibitive storage cost of using .accept to do the job of .resolve. Storage aside, there is no semantic need to distinguish these two.
(Note that if anyone thinks we need something that eagerly flattens a promise, rather than flattening happening implicitly via the definition of "fulfilled value" for then(), realize that this eager flattening operation is hostile to lazy promises. While this might be useful in some cases, it's probably not something we need or want in the core language, or if we do, it should be given an appropriately descriptive name, rather than yet another synonym for "accept".)
I agree that we do not need eager flattening.
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller <erights at google.com> wrote:
At the P2.then level
Should be "At the AP2.then level"
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller <erights at google.com> wrote:
I'm not so much concerned with the static .resolve method, since the extra storage cost for the static method is negligible. However, what does aResolve.resolve do?
Should be "What does aResolver.resolve do?"
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller <erights at google.com> wrote:
To answer this precisely, we need good terminology to distinguish two levels of abstraction: The distinctions observable to the AP2.flatMap programmer and the coarser distinctions observable to the AP2.then programmer. Let's start ignoring thenables and considering only promises-vs-non-promises. Let's also start by ignoring rejection.
At the AP2.flatMap level,
- for a promise p and an arbitrary value v, p may accept v. p is then in the "accepted" state.
- for a promise p and a promise q, p may adopt q. p is then in the "adopting" state. Putting these together, we can also say
- for a promise p and an arbitrary value v, p is resolved to v if p either accepts v or adopts v. p is then in the "resolved" state.
p2 = p1.flatMap(v1 => q2)
means, if p1 is accepted, then v1 will be what it has accepted.
If q2 is a promise, then p2 adopts q2.
p2.flatMap(...) fires as a result of acceptance but not adoption. If q2 accepts, then p2 likewise accepts and p2.flatMap fires by virtue of this acceptance.
At the P2.then level
- for a promise p and a non-promise v, p may be fulfilled with v. p is then in the fulfulled state.
- for a promise p and a promise q, p may follow q. p is then in the following state.
- Until a promise p is either fulfilled or rejected, it is pending. Putting these together, we can also say
- for a promise p and an arbitrary value v, p is resolved to v if either p is fulfilled with v or p follows v. p is then in the "resolved" state.
p4 = p3.then(v3 => v4)
means, if p3 is fulfilled, then v3 will be what p3 is fulfilled with.
p4 is resolved to v4. If v4 is a promise, then p4 follows v4. Else p4 is fulfilled with v4.
p4.then fires as a result of fulfillment but not following. If p4 follows v4 and v4 fulfills, then p4 likewise fulfills and p4.then fires by virtue of this fulfillment.
Notice that "resolved" is the same states at each level, even though these states are described differently. That is why we can use the same term at both levels. Likewise, the concept of "unresolved" is meaningful at both levels.
Argh, I knew this would turn into another confusing terminology discussion. ^_^
I'm not quite getting this. Why are you using "resolved" in this way? It doesn't seem to map to a useful state for either mode, since you're munging together the case where v4 is a value (p4 can call its callbacks) and where v4 is a promise (p4 maybe can't call its callbacks yet, or ever, depending on v4's state). You're also munging together the case where q2 is pending vs not-pending, which again means that either p2 can call its callbacks or not.
In my email, and I think Domenic in his, I'm trying to nail down some terms that map to useful states, capturing observable distinctions in behavior:
"resolved" means a promise contains a value - it's no longer pending.
Your p2 is resolved only when q2 becomes resolved, due to adoption
semantics. (If you were to put q2 directly into another promise, via
p2 = Promise.resolve(q2), then p2 would be resolved. Adoption
semantics flatten one level, but Promise.resolve() isn't adopting.)
A promise is "resolved" when it would call its flatMap() callbacks.
"fulfilled", taken from Promises/A+, means a promise contains a non-promise value, or contains a fulfilled promise. Your p4 is only fulfilled if v4 is a non-promise value, or is a fulfilled promise.
So, a promise starts out "pending", becomes "resolved", and then becomes "fulfilled". This ordering is always preserved, though some states might happen at the same time.
If necessary, we can come up with distinct terms for "not resolved" and "not fulfilled", since a promise can be resolved but not fulfilled. (This is exactly the state that p4 is in if v4 is a non-fulfilled promise.) "Not fulfilled" = "pending" (Promises/A+ meaning) and "not resolved" = "super pending"? ^_^
We could use the terms differently than what I've defined here, but why?
I'm not so much concerned with the static .resolve method, since the extra storage cost for the static method is negligible. However, what does aResolve.resolve do? If it causes its promise to accept, this must be observably different to .flatMap observers than if it causes its promise to adopt. This difference is not observable to .then observers, which is why I've accidentally missed this issue twice now. But since an implementation cannot know ahead of time whether there might be .flatMap observers, using .accept for .resolve would impose prohibitive storage costs on .then oriented patterns. See the message Anne linked to.
I'm not entirely certain I get your point, so let me restate in code and hopefully clearer text. Given this code:
p1 = Promise.resolve(v1) p2 = Promise.resolve(p1)
p2.flatMap(print) would print the p1 object, but p2.then(print) would print v1. If p2 was the only thing referring to p1, and we somehow knew that you'd only interact with p2 via .then(), we could GC p1 and just keep v1 around. However, since we don't know that, we have to keep both p1 and v1 around, which is an extra memory cost.
Is this what you were referring to?
(I have no idea why this paragraph I'm responding to draws a
distinction between Promise.resolve() and the
PromiseResolver#resolve() method, though. Promise.resolve(v1) is
exactly identical to new Promise(r=>r.resolve(v1)) - it's just a
typing shortcut.)
(Note that if anyone thinks we need something that eagerly flattens a promise, rather than flattening happening implicitly via the definition of "fulfilled value" for then(), realize that this eager flattening operation is hostile to lazy promises. While this might be useful in some cases, it's probably not something we need or want in the core language, or if we do, it should be given an appropriately descriptive name, rather than yet another synonym for "accept".)
I agree that we do not need eager flattening.
I don't understand what you're asking for, then.
On Tue, Aug 20, 2013 at 11:04 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
Argh, I knew this would turn into another confusing terminology discussion. ^_^
Indeed ;).
I think this is because you more naturally think at the AP2.flatMap level of abstraction and derive AP2.then level concepts from that. And vice versa for me. That's why I tried to clearly lay out and distinctly name the concepts relevant at each level.
I'm not quite getting this. Why are you using "resolved" in this way?
Because it corresponds to how "resolved" has historically been used in Promses/A+ ever since the Promises/A+ distinguished "resolved" vs "settled". It also describes what .resolve does. Your proposed meaning of .resolve if what I'm calling .accept. To the AP2.then observer, this also does the job historically associated with .resolve, but at a prohibitive storage cost for .then oriented patterns. Using .accept for .resolve would be much like using a non-tail-recursive language implementation to execute algorithms written assuming tail recursion optimization.
The relationship between the two is:
resolve(v) => { isPromise(v) ? adopt(v) : accept(v) }
except that I am not proposing that an explicit "adopt" method be added to the API.
It doesn't seem to map to a useful state for either mode, since you're munging together the case where v4 is a value (p4 can call its callbacks) and where v4 is a promise (p4 maybe can't call its callbacks yet, or ever, depending on v4's state).
I'm just restating the semantics I thought we agreed on. From the AP2.then perspective p4 resolves to v4. From the AP2.flatMap perspective, if v4 is a promise, p4 adopts v4. Otherwise p4 accepts v4.
The only alternative I see is that p4 always accepts v4. This would accumulate an explicit layer of wrapping for each level of then-return, since these layers would need to be observable by .flatMap (unless the implementation can prove that p4 will never be observed with .flatMap, which is unlikely to be common).
Regarding the calling of p4.then callbacks, your summary is correct: if v4 is a non-promise, then p4 fulfills to it and p4.then can call its callbacks. If v4 is a pending promise, then p4.then cannot yet call its callbacks. What am I missing? What is being munged?
You're also munging together the case where q2 is pending vs not-pending, which again means that either p2 can call its callbacks or not.
I'm using the term "pending" at the AP2.then level, to mean "not fulfilled or rejected". The similar concept at the AP2 level isn't something we've previously named, but it means "not accepted". Here I will use "unaccepted".
So I don't know what you mean by munging. I thought we agreed that p2 adopts q2, and while q2 is unaccepted, p2 is unaccepted as well and p2.flatMap cannot call its callbacks. Once q2 becomes accepting, then p2 becomes accepting as well and p2.flatMap can call its callbacks. Are we in agreement?
In my email, and I think Domenic in his, I'm trying to nail down some terms that map to useful states, capturing observable distinctions in behavior:
"resolved" means a promise contains a value - it's no longer pending.
Domenic clarified that the modern term for "no longer pending", i.e., fulfilled or rejected, is "settled". Perhaps this is the source of confusion? In E, Waterken, perhaps AmbientTalk, and in historically earlier versions of the Promises/A+ spec, we used to say "resolved" for what we now call "settled". We changed this terminology precisely because of the conflict that the .resolve operation did not cause a promise to be what we had called "resolved" and now call "settled".
Your p2 is resolved only when q2 becomes resolved, due to adoption semantics.
Ok, this hypothesis fits. It is true that
p2 is settled only when q2 becomes settled, due to adoption
semantics.
However, the original is not true. Since .resolve either adopts or accepts, p2 is resolved as soon as it adopts q2.
OTOH, the previous hypothesis that your "resolved" is my "accepted" also fits:
p2 is accepted only when q2 becomes accepted due to adoption
semantics.
I can guess which rewrite better fits what you're trying to say, but I'll let you clarify.
(If you were to put q2 directly into another promise, via
p2 = Promise.resolve(q2), then p2 would be resolved.
yes.
Adoption semantics flatten one level, but
Promise.resolve()isn't adopting.)
This is true for .accept.
A promise is "resolved" when it would call its flatMap() callbacks.
Again true for "accepted".
"fulfilled", taken from Promises/A+, means a promise contains a non-promise value, or contains a fulfilled promise.
Ignoring thenables as we're doing here, yes.
Your p4 is only fulfilled if v4 is a non-promise value, or is a fulfilled promise.
yes.
So, a promise starts out "pending", becomes "resolved", and then becomes "fulfilled". This ordering is always preserved, though some states might happen at the same time.
Not quite. A promise starts out pending an unresolved. If p5 is resolved to p6 and p6 is pending, then p5 is both pending and resolved.
If necessary, we can come up with distinct terms for "not resolved"
"unresolved"
and "not fulfilled",
"pending" === "not fulfilled and not rejected"
since a promise can be resolved but not fulfilled. (This is exactly the state that p4 is in if v4 is a non-fulfilled promise.)
"Not fulfilled" = "pending" (Promises/A+ meaning)
yes, ignoring rejected as we are doing here.
and "not resolved" = "super pending"? ^_^
"unresolved"
We could use the terms differently than what I've defined here, but why?
I think you're missing one distinction, as you're using "resolved" for what I'm calling "accepted" and you have no name for what I'm calling "resolved". By presuming that the accept operation is used for cases that Promises/A+ uses the resolve, you impose prohibitive storage costs.
I'm not so much concerned with the static .resolve method, since the extra storage cost for the static method is negligible.
Replying to myself here, I retract that statement of non-concern, since the static .resolve method would be the std method to be used the way the Q function is currently used. The static .resolve method's behavior, in terms of .accept, is
Promise.resolve = v => ( isPromise(v) ? v : Promise.accept(v) );
This avoids even a transient allocation cost when Promise.resolve is used to coerce (or auto-lift if you wish) a possible promise into a guaranteed promise.
However, what does
aResolve.resolve do? If it causes its promise to accept, this must be observably different to .flatMap observers than if it causes its promise to adopt. This difference is not observable to .then observers, which is why I've accidentally missed this issue twice now. But since an implementation cannot know ahead of time whether there might be .flatMap observers, using .accept for .resolve would impose prohibitive storage costs on .then oriented patterns. See the message Anne linked to.
I'm not entirely certain I get your point, so let me restate in code and hopefully clearer text. Given this code:
p1 = Promise.resolve(v1) p2 = Promise.resolve(p1)
p2.flatMap(print) would print the p1 object, but p2.then(print) would print v1. If p2 was the only thing referring to p1, and we somehow knew that you'd only interact with p2 via .then(), we could GC p1 and just keep v1 around. However, since we don't know that, we have to keep both p1 and v1 around, which is an extra memory cost.
Is this what you were referring to?
Exactly! When going around a tail recursive async loop, these unnecessary p1s pile up. See Q.async at < strawman:async_functions#reference_implementation>
for example.
(I have no idea why this paragraph I'm responding to draws a distinction between Promise.resolve() and the PromiseResolver#resolve() method, though.
Promise.resolve(v1)is exactly identical tonew Promise(r=>r.resolve(v1))- it's just a typing shortcut.)
In that previous message of mine, that distinction was indeed unnecessary. It was only because I wanted to emphasize the PromiseResolver#resolve case, as it seemed clearer to me that we can't afford the extra wrapping there. However, I was wrong.
Nevertheless, the distinction here may or may not be needed depending on your answer to a question: In
new Promise(r=>r.resolve(v1))
if v1 is a promise, does this "new" call return v1 itself? Clearly, if the resolver is only stored during construction and called later, the answer would be no. The returned promise can only adopt v1 later. But literally in the code above the resolver's .resolve method is called during construction, so this seems a sensible option. OTOH, even though it is an allowed behavior for "new" to not return a fresh object, so I think I prefer the answer "no, the 'new Promise(...)' expression must return a fresh promise".
If the answer is yes, then indeed the two expressions mean exactly the same thing.
(Note that if anyone thinks we need something that eagerly flattens a promise, rather than flattening happening implicitly via the definition of "fulfilled value" for then(), realize that this eager flattening operation is hostile to lazy promises. While this might be useful in some cases, it's probably not something we need or want in the core language, or if we do, it should be given an appropriately descriptive name, rather than yet another synonym for "accept".)
I agree that we do not need eager flattening.
I don't understand what you're asking for, then.
Did anything in any of my messages imply that I desire eager flattening?
On Tue, Aug 20, 2013 at 8:55 PM, Mark S. Miller <erights at google.com> wrote:
OTOH, even though it is an allowed behavior for "new" to not return a fresh object, so I think I prefer
Should be: "...even though it is an allowed behavior for 'new' to not return a fresh object, it is surprising, so I think I prefer..."
On Tue, Aug 20, 2013 at 8:55 PM, Mark S. Miller <erights at google.com> wrote:
On Tue, Aug 20, 2013 at 11:04 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
Argh, I knew this would turn into another confusing terminology discussion. ^_^
Indeed ;).
I think this is because you more naturally think at the AP2.flatMap level of abstraction and derive AP2.then level concepts from that. And vice versa for me. That's why I tried to clearly lay out and distinctly name the concepts relevant at each level.
Well, one is lower-level than the other, so I think it makes sense to think of it my way. ^_^
I'm not quite getting this. Why are you using "resolved" in this way?
Because it corresponds to how "resolved" has historically been used in Promses/A+ ever since the Promises/A+ distinguished "resolved" vs "settled". It also describes what .resolve does. Your proposed meaning of .resolve if what I'm calling .accept. To the AP2.then observer, this also does the job historically associated with .resolve, but at a prohibitive storage cost for .then oriented patterns. Using .accept for .resolve would be much like using a non-tail-recursive language implementation to execute algorithms written assuming tail recursion optimization.
Ignoring the storage issue, the point of this thread is that the current accept/resolve semantics are indistinguishable for .then(), and unnecessary/confusing for .flatMap().
It's fine to use "resolve" in the A+ sense even if the technical definition is just "puts an arbitrary value in the promise", because you can't tell the difference from .then().
The relationship between the two is:
resolve(v) => { isPromise(v) ? adopt(v) : accept(v) }except that I am not proposing that an explicit "adopt" method be added to the API.
Ah, this is why I thought you wanted a deep flattening operation - adoption semantics aren't quite what Promises/A+ uses.
I guess I'm okay with resolve() adopting promises and just fulfilling with other values, if we still have an op which solely puts a value into the promise.
It doesn't seem to map to a useful state for either mode, since you're munging together the case where v4 is a value (p4 can call its callbacks) and where v4 is a promise (p4 maybe can't call its callbacks yet, or ever, depending on v4's state).
I'm just restating the semantics I thought we agreed on. From the AP2.then perspective p4 resolves to v4. From the AP2.flatMap perspective, if v4 is a promise, p4 adopts v4. Otherwise p4 accepts v4.
The only alternative I see is that p4 always accepts v4. This would accumulate an explicit layer of wrapping for each level of then-return, since these layers would need to be observable by .flatMap (unless the implementation can prove that p4 will never be observed with .flatMap, which is unlikely to be common).
Regarding the calling of p4.then callbacks, your summary is correct: if v4 is a non-promise, then p4 fulfills to it and p4.then can call its callbacks. If v4 is a pending promise, then p4.then cannot yet call its callbacks. What am I missing? What is being munged?
You're also munging together the case where q2 is pending vs not-pending, which again means that either p2 can call its callbacks or not.
I'm using the term "pending" at the AP2.then level, to mean "not fulfilled or rejected". The similar concept at the AP2 level isn't something we've previously named, but it means "not accepted". Here I will use "unaccepted".
So I don't know what you mean by munging. I thought we agreed that p2 adopts q2, and while q2 is unaccepted, p2 is unaccepted as well and p2.flatMap cannot call its callbacks. Once q2 becomes accepting, then p2 becomes accepting as well and p2.flatMap can call its callbacks. Are we in agreement?
Yes, the mechanics of what happens are clear and agreed-on. But that doesn't mean that the action matches a useful state. I think the only useful things to call "states" are the observable ones where a particular callback is called. Any other states we might invent may be useful for talking about things internally, but that's of lesser importance.
In my email, and I think Domenic in his, I'm trying to nail down some terms that map to useful states, capturing observable distinctions in behavior:
"resolved" means a promise contains a value - it's no longer pending.
Domenic clarified that the modern term for "no longer pending", i.e., fulfilled or rejected, is "settled". Perhaps this is the source of confusion? In E, Waterken, perhaps AmbientTalk, and in historically earlier versions of the Promises/A+ spec, we used to say "resolved" for what we now call "settled". We changed this terminology precisely because of the conflict that the .resolve operation did not cause a promise to be what we had called "resolved" and now call "settled".
"fulfilled or rejected" is different from "contains a value" in our context, because a promise can contain a pending promise. This will still call .flatMap() callbacks. Promises/A+'s use of "settled" to mean "fulfilled or rejected" is fine with me.
Your p2 is resolved only when q2 becomes resolved, due to adoption semantics.
Ok, this hypothesis fits. It is true that
p2 is settled only when q2 becomes settled, due to adoption semantics.However, the original is not true. Since .resolve either adopts or accepts, p2 is resolved as soon as it adopts q2.
OTOH, the previous hypothesis that your "resolved" is my "accepted" also fits:
p2 is accepted only when q2 becomes accepted due to adoptionsemantics.
I can guess which rewrite better fits what you're trying to say, but I'll let you clarify.
Yes, your latter implication is precisely what Domenic started this thread with, and what I've been talking about so far in this thread.
So, a promise starts out "pending", becomes "resolved", and then becomes "fulfilled". This ordering is always preserved, though some states might happen at the same time.
Not quite. A promise starts out pending an unresolved. If p5 is resolved to p6 and p6 is pending, then p5 is both pending and resolved.
Yeah, if "pending" means "not fulfilled", which is the Promises/A+ meaning, then this is true. I'm fine with that.
Replying to myself here, I retract that statement of non-concern, since the static .resolve method would be the std method to be used the way the Q function is currently used. The static .resolve method's behavior, in terms of .accept, is
Promise.resolve = v => ( isPromise(v) ? v : Promise.accept(v) );This avoids even a transient allocation cost when Promise.resolve is used to coerce (or auto-lift if you wish) a possible promise into a guaranteed promise.
I don't think we want Promise.resolve() to only sometimes return a new promise.
I'm not entirely certain I get your point, so let me restate in code and hopefully clearer text. Given this code:
p1 = Promise.resolve(v1) p2 = Promise.resolve(p1)
p2.flatMap(print) would print the p1 object, but p2.then(print) would print v1. If p2 was the only thing referring to p1, and we somehow knew that you'd only interact with p2 via .then(), we could GC p1 and just keep v1 around. However, since we don't know that, we have to keep both p1 and v1 around, which is an extra memory cost.
Is this what you were referring to?
Exactly! When going around a tail recursive async loop, these unnecessary p1s pile up. See Q.async at strawman:async_functions#reference_implementation for example.
Yeah, makes sense.
(I have no idea why this paragraph I'm responding to draws a distinction between Promise.resolve() and the PromiseResolver#resolve() method, though.
Promise.resolve(v1)is exactly identical tonew Promise(r=>r.resolve(v1))- it's just a typing shortcut.)In that previous message of mine, that distinction was indeed unnecessary. It was only because I wanted to emphasize the PromiseResolver#resolve case, as it seemed clearer to me that we can't afford the extra wrapping there. However, I was wrong.
Nevertheless, the distinction here may or may not be needed depending on your answer to a question: In
new Promise(r=>r.resolve(v1))if v1 is a promise, does this "new" call return v1 itself? Clearly, if the resolver is only stored during construction and called later, the answer would be no. The returned promise can only adopt v1 later. But literally in the code above the resolver's .resolve method is called during construction, so this seems a sensible option. OTOH, even though it is an allowed behavior for "new" to not return a fresh object, so I think I prefer the answer "no, the 'new Promise(...)' expression must return a fresh promise".
If the answer is yes, then indeed the two expressions mean exactly the same thing.
I meant it in the strict sense - that's literally a desugaring of Promise.resolve().
Excellent excellent! It seems we are in agreement and clarity on all terminology issue, and on almost complete agreement on substantive issues. The only remaining issue is whether either of the following expressions always return a fresh promise, and if they are exactly equivalent:
a) Promise.resolve(v1) b) new Promise(r=>r.resolve(v1))
When v1 is a promise, x) I prefer that #a return v1 and #b return a fresh promise that adopts v1. y) You prefer that both #a and #b return a fresh promise z) The fewest feasible allocations would have both return v1. w) I do not expect anyone will want #a to return a fresh promise and #b to return v1.
We both agree that if we settle on either #y or #z, then #a and #b are equivalent. Otherwise they are equivalent up to this issue.
The reason I prefer that #b return a fresh promise is that it is surprising for a "new" expression to return something other than a fresh object.
The reason I prefer #a is that the primary use case for #a is coercion -- given possible promise v1, gimme a guaranteed genuine promise that designates the same (possibly eventual) non-promise. See calls to the Q() function at strawman:concurrency and es-lab.googlecode.com/svn/trunk/src/ses/contract (which corresponds to research.google.com/pubs/pub40673.html ). These calls are numerous and necessary, and sufficiently frequent that the extra transient allocation in the typical case will be a noticeable cost.
If this is indeed the only outstanding issue, I think this overall thread can declare victory, noting that this one detail remains to be, um, resolved ;).
On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller <erights at google.com> wrote:
Excellent excellent! It seems we are in agreement and clarity on all terminology issue, and on almost complete agreement on substantive issues. The only remaining issue is whether either of the following expressions always return a fresh promise, and if they are exactly equivalent:
a) Promise.resolve(v1) b) new Promise(r=>r.resolve(v1))
When v1 is a promise, x) I prefer that #a return v1 and #b return a fresh promise that adopts v1. y) You prefer that both #a and #b return a fresh promise z) The fewest feasible allocations would have both return v1. w) I do not expect anyone will want #a to return a fresh promise and #b to return v1.
We both agree that if we settle on either #y or #z, then #a and #b are equivalent. Otherwise they are equivalent up to this issue.
The reason I prefer that #b return a fresh promise is that it is surprising for a "new" expression to return something other than a fresh object.
I think it's super bizarre for a class static to act differently from the trivial desugaring to the same-named instance method. (In this case, it's not quite an instance method, but close enough. ^_^ It would be an instance method if we weren't caring about capability grants.)
The reason I prefer #a is that the primary use case for #a is coercion -- given possible promise v1, gimme a guaranteed genuine promise that designates the same (possibly eventual) non-promise. See calls to the Q() function at strawman:concurrency and es-lab.googlecode.com/svn/trunk/src/ses/contract (which corresponds to research.google.com/pubs/pub40673.html ). These calls are numerous and necessary, and sufficiently frequent that the extra transient allocation in the typical case will be a noticeable cost.
That's reasonable, but we should do it with a different function that just promotes things into promises, or leave it to library code when they need it. (We don't, for example, have such an operation for Array/Map/Set, though I have used such an operation before.)
On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
That's reasonable, but we should do it with a different function that just promotes things into promises,
Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
How about just Promise, following String, Number, RegExp, etc.?
(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)
On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com<mailto:erights at google.com>> wrote:
On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage at gmail.com<mailto:jackalmage at gmail.com>> wrote:
On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller <erights at google.com<mailto:erights at google.com>> wrote:
Excellent excellent! It seems we are in agreement and clarity on all terminology issue, and on almost complete agreement on substantive issues. The only remaining issue is whether either of the following expressions always return a fresh promise, and if they are exactly equivalent:
a) Promise.resolve(v1) b) new Promise(r=>r.resolve(v1))
When v1 is a promise, x) I prefer that #a return v1 and #b return a fresh promise that adopts v1. y) You prefer that both #a and #b return a fresh promise z) The fewest feasible allocations would have both return v1. w) I do not expect anyone will want #a to return a fresh promise and #b to return v1.
We both agree that if we settle on either #y or #z, then #a and #b are equivalent. Otherwise they are equivalent up to this issue.
The reason I prefer that #b return a fresh promise is that it is surprising for a "new" expression to return something other than a fresh object.
I think it's super bizarre for a class static to act differently from the trivial desugaring to the same-named instance method. (In this case, it's not quite an instance method, but close enough. ^_^ It would be an instance method if we weren't caring about capability grants.)
The reason I prefer #a is that the primary use case for #a is coercion -- given possible promise v1, gimme a guaranteed genuine promise that designates the same (possibly eventual) non-promise. See calls to the Q() function at strawman:concurrency and es-lab.googlecode.com/svn/trunk/src/ses/contract (which corresponds to research.google.com/pubs/pub40673.html ). These calls are numerous and necessary, and sufficiently frequent that the extra transient allocation in the typical case will be a noticeable cost.
That's reasonable, but we should do it with a different function that just promotes things into promises,
Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
or leave it to library code when they need it. (We don't, for example, have such an operation for Array/Map/Set, though I have used such an operation before.)
On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com> wrote:
Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
How about just
Promise, followingString,Number,RegExp, etc.?(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)
Yeah, that's the existing coercer idiom. The other one that's close is Array.from(). It still always produces a new object, but that doesn't necessarily have to be a property of every class's usage.
But I like just Promise(), sans "new".
Also, while we've settled on "resolve" still retaining its current semantics (promises get adopted, other values just fulfill the promise directly), I think the other part of Domenic's proposal - removing "accept" from the resolver - is still reasonable. There's no behavioral difference between resolving and accepting for .then(), so we don't need it there, and you already need to be careful that your value is wrapped in a promise for .flatMap() callbacks, so requiring the same for the resolver function when those are the semantics you want is fine with me.
We'll still need the class static for it, just not the resolver function. I propose we quit with the synonyms, and use Promise.of() like I (and others) proposed a long time ago. ^_^
On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com> wrote:
Good idea. As a coercing function, a natural name is Promise.as(v1). Also,
as a common coercer, brevity is a virtue.
How about just
Promise, followingString,Number,RegExp, etc.?(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)
Yeah, that's the existing coercer idiom. The other one that's close is Array.from(). It still always produces a new object, but that doesn't necessarily have to be a property of every class's usage.
But I like just Promise(), sans "new".
Good. I like it too, and Allen's latest draft class semantics enables the definition of classes that can do this reliably. But is there any way to reliably polyfill this in ES5? It's not clear. For the std promise API, given the urgency with which people want to use it now, I think this polyfillability is important.
Also, while we've settled on "resolve" still retaining its current semantics (promises get adopted, other values just fulfill the promise directly), I think the other part of Domenic's proposal - removing "accept" from the resolver - is still reasonable.
Good. +1.
There's no behavioral difference between resolving and accepting for .then(), so we don't need it there, and you already need to be careful that your value is wrapped in a promise for .flatMap() callbacks, so requiring the same for the resolver function when those are the semantics you want is fine with me.
I did not understand this reasoning even though I like its conclusion. Could you expand on this, perhaps with examples? Thanks.
We'll still need the class static for it, just not the resolver function. I propose we quit with the synonyms, and use Promise.of() like I (and others) proposed a long time ago. ^_^
I do not love this but I do not object. +0.8 ;).
On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller <erights at google.com> wrote:
On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com> wrote:
Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
How about just
Promise, followingString,Number,RegExp, etc.?(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)
Yeah, that's the existing coercer idiom. The other one that's close is Array.from(). It still always produces a new object, but that doesn't necessarily have to be a property of every class's usage.
But I like just Promise(), sans "new".
Good. I like it too, and Allen's latest draft class semantics enables the definition of classes that can do this reliably. But is there any way to reliably polyfill this in ES5? It's not clear. For the std promise API, given the urgency with which people want to use it now, I think this polyfillability is important.
Yes, why wouldn't it be? The test for promise-ness can be done today,
without special browser privilege, and distinguishing between
Promise(foo) and new Promise(foo) is a trivial matter of testing
the type of this inside the function. (If it's instanceof Promise,
you were called with new. Otherwise, you weren't. This isn't 100%,
as people can fool you with Promise.call(), but that's not something
you need to actually worry about, I think.)
There's no behavioral difference between resolving and accepting for .then(), so we don't need it there, and you already need to be careful that your value is wrapped in a promise for .flatMap() callbacks, so requiring the same for the resolver function when those are the semantics you want is fine with me.
I did not understand this reasoning even though I like its conclusion. Could you expand on this, perhaps with examples? Thanks.
Okay.
For .then(), you can't tell the difference between adopting and just fulfilling with a promise, because both will wait for the inner promise to fulfill before the outer promise fulfills. So obviously you don't need a resolver function for "just wrap it" if you're using .then().
For .flatMap(), there's a clear difference between the two. However, we should probably engineer toward making things similar for the resolver and a .flatMap() callback. In a callback, if you want to return a nested promise, you have to first wrap it in a throwaway promise (which will then get adopted away). That is:
p1.flatMap(x=>p2).flatMap(print) // prints whatever value p2 resolves to
p1.flatMap(x=>Promise.of(p2)).flatMap(print) // prints p2 itself, not
its resolved value
Similarly, if you limit yourself to just the resolve/reject resolver functions:
new Promise(r=>r.resolve(p2)).flatMap(print) // prints whatever value
p2 resolves to new Promise(r=>r.resolve(Promise.of(p2))).flatMap(print) // prints p2
itself, not its resolved value
On the other hand, if you allow the accept resolver function:
new Promise(r=>r.accept(pw)).flatMap(print) // prints p2 itself, not
its resolved value
I'm fine with requiring the bit of extra work that's needed without accept, due to the symmetry - Resolver#resolve is exactly identical to returning from a callback, and Resolver#reject is exactly identical to throwing from a callback, but there's no way to duplicate Resolver#accept from a callback, and thus it's not clear that this functionality is actually needed.
We'll still need the class static for it, just not the resolver function. I propose we quit with the synonyms, and use Promise.of() like I (and others) proposed a long time ago. ^_^
I do not love this but I do not object. +0.8 ;).
Cool. That means we get a decent naming precedent for the monad ops, and consistency with Array.of (which also happens to be a monadic lifter, if you limit yourself to calling it with only a single argument).
On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller <erights at google.com> wrote:
On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
On Aug 21, 2013, at 18:31, "Mark S. Miller" <erights at google.com> wrote:
Good idea. As a coercing function, a natural name is Promise.as(v1). Also, as a common coercer, brevity is a virtue.
How about just
Promise, followingString,Number,RegExp, etc.?(I tend to agree with Tab that both #a and #b should return a new promise. But we do need an easy coercion function, as Mark emphasizes.)
Yeah, that's the existing coercer idiom. The other one that's close is Array.from(). It still always produces a new object, but that doesn't necessarily have to be a property of every class's usage.
But I like just Promise(), sans "new".
Good. I like it too, and Allen's latest draft class semantics enables the definition of classes that can do this reliably. But is there any way to reliably polyfill this in ES5? It's not clear. For the std promise API, given the urgency with which people want to use it now, I think this polyfillability is important.
Yes, why wouldn't it be? The test for promise-ness can be done today, without special browser privilege, and distinguishing between
Promise(foo)andnew Promise(foo)is a trivial matter of testing the type ofthisinside the function. (If it's instanceof Promise, you were called with new. Otherwise, you weren't. This isn't 100%, as people can fool you with Promise.call(), but that's not something you need to actually worry about, I think.)
This is an example of what I am worried about. Another is
Object.create(p, {value: Promise}).Promise(....)
where p is a promise.
Perhaps it would help if, when we start to think "people can fool you with..." it would help to substitute "an attacker can fool you with...".
There's no behavioral difference between resolving and accepting for .then(), so we don't need it there, and you already need to be careful that your value is wrapped in a promise for .flatMap() callbacks, so requiring the same for the resolver function when those are the semantics you want is fine with me.
I did not understand this reasoning even though I like its conclusion. Could you expand on this, perhaps with examples? Thanks.
Okay.
For .then(), you can't tell the difference between adopting and just fulfilling with a promise, because both will wait for the inner promise to fulfill before the outer promise fulfills. So obviously you don't need a resolver function for "just wrap it" if you're using .then().
For .flatMap(), there's a clear difference between the two. However, we should probably engineer toward making things similar for the resolver and a .flatMap() callback. In a callback, if you want to return a nested promise, you have to first wrap it in a throwaway promise (which will then get adopted away). That is:
p1.flatMap(x=>p2).flatMap(print) // prints whatever value p2 resolves to p1.flatMap(x=>Promise.of(p2)).flatMap(print) // prints p2 itself, not its resolved value
Similarly, if you limit yourself to just the resolve/reject resolver functions:
new Promise(r=>r.resolve(p2)).flatMap(print) // prints whatever value p2 resolves to new Promise(r=>r.resolve(Promise.of(p2))).flatMap(print) // prints p2 itself, not its resolved value
Aha. Good I get it. Yes, I enthusiastically agree.
On the other hand, if you allow the accept resolver function:
new Promise(r=>r.accept(pw)).flatMap(print) // prints p2 itself, not its resolved value
I'm fine with requiring the bit of extra work that's needed without accept, due to the symmetry - Resolver#resolve is exactly identical to returning from a callback, and Resolver#reject is exactly identical to throwing from a callback, but there's no way to duplicate Resolver#accept from a callback, and thus it's not clear that this functionality is actually needed.
Yes.
We'll still need the class static for it, just not the resolver function. I propose we quit with the synonyms, and use Promise.of() like I (and others) proposed a long time ago. ^_^
I do not love this but I do not object. +0.8 ;).
Cool. That means we get a decent naming precedent for the monad ops, and consistency with Array.of (which also happens to be a monadic lifter, if you limit yourself to calling it with only a single argument).
I agree that this naming analogy is a good thing. I raise my approval magnitude to +1 ;).
Bart: Are we there yet? Homer: Just a little further... Bart: Are we there yet? Homer: Just a little further... etc.
Can someone summarize for those of us who accidentally skipped a bunch of unread messages here? It sounds good from the last post ;-).
Meta summary: AFAICT, Tab and I are in 100% agreement on all issues either of us has raised!
An non-meta summary will take more time ;).
On Wed, Aug 21, 2013 at 6:00 PM, Brendan Eich <brendan at mozilla.com> wrote:
Can someone summarize for those of us who accidentally skipped a bunch of unread messages here? It sounds good from the last post ;-).
Yup!
- Keep Promise.resolve() as it currently works (but make sure that it merely adopts promises passed to it, rather than deep-flattens).
- Rename Promise.accept() to Promise.of() (for consistency with Array.of, and to provide a better naming base for monads in the future).
- Kill PromiseResolver#accept().
- Make Promise() called without new analogous to String/etc - passing it a promise returns the argument unchanged, passing it anything else wraps it in a fresh promise.
~TJ
On Wed, Aug 21, 2013 at 6:04 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
4. Make Promise() called without new analogous to String/etc - passing it a promise returns the argument unchanged, passing it anything else wraps it in a fresh promise.
Assuming that we can polyfill this new-vs-non-new behavior test reliably on ES5. Otherwise we still need a static method such as Promise.as().
I am generally against sacrificing things for polyfillability. I'd rather say "if you're using this polyfill and need security guarantees, use Promise.as (or Q, even); if you want forward-compatibility at the expense of security, use Promise."
Other options could involve using the module system. Indeed, all static methods could in theory move there. The default export even could be the coercer (like it is with Q today).
import { toPromise as Q, every, some, Promise } from "@promise"; // renaming to Q for brevity
// or maybe
import Q from "@promise";
import { every, some, Promise } from "@promise";
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller <erights at google.com> wrote:
This is an example of what I am worried about. Another is
Object.create(p, {value: Promise}).Promise(....)where p is a promise.
Perhaps it would help if, when we start to think "people can fool you with..." it would help to substitute "an attacker can fool you with...".
An attacker can already fool you with a promise-like, so I don't think
this opens up any additional vectors. Unless you wanted promise-likes
to return fresh objects too? That would be a third case, and
potentially confusing for people. On the other hand, it would mean
that the return value of Promise(foo) is always instanceof Promise.
The only way to have a completely reliable type test is to use a WeakSet to keep track of instances, or store a brand on the object in a way that only the browser can read/write (such as in the C++ backing, for example). Do you consider WeakMaps sufficient for polyfillability? If so, then we're clear.
From: Tab Atkins Jr. [mailto:jackalmage at gmail.com]
Unless you wanted promise-likes to return fresh objects too?
Yes, that is largely the use case for Q/Promise.as/whatever. Handing it untrusted input, possible a non-promise, possibly a promise-like, possibly a promise, and getting back a trusted promise.
The only way to have a completely reliable type test is to use a WeakSet to keep track of instances
I believe this is what Mark's makeQ.js does.
Do you consider WeakMaps sufficient for polyfillability?
I believe makeQ.js uses a WeakMap polyfill, so yes.
On Wed, Aug 21, 2013 at 7:13 PM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
From: Tab Atkins Jr. [mailto:jackalmage at gmail.com]
Unless you wanted promise-likes to return fresh objects too?
Yes, that is largely the use case for
Q/Promise.as/whatever. Handing it untrusted input, possible a non-promise, possibly a promise-like, possibly a promise, and getting back a trusted promise.
Okay, that makes sense.
The only way to have a completely reliable type test is to use a WeakSet to keep track of instances
I believe this is what Mark's makeQ.js does.
Do you consider WeakMaps sufficient for polyfillability?
I believe makeQ.js uses a WeakMap polyfill, so yes.
Cool.
First, yes, relying of ES5 + WeakMap is fine, since we have a reliable and secure (though painful and leaky) WeakMap polyfill for ES5. However, even with that, how do you construct a function which can distinguish whether it is called with "new" or not?
Correction to meta-summary. We got to this state of happy agreement by purposely postponing two issues:
a) We encapsulated the question of "what is a thenable?" into an abstract isThenable(v) function which we have postponed defining.
b) We have postponed pinning down what happens if one attempts to subclass Promise.
Since the immediate issue is, what do we need to agree on to unblock DOM, I think we can continue to postpone #b for a while. However, we still need to settle #a asap. There are two approaches:
compat-duck) Maintain compatibility with Promise/A+ and thus with libraries
compatible with Promises/A+ and the clients of those libraries, grit our
teeth (like we did for __proto__) and codify its duck typing of thenables,
to whit:
function isThenable(o) {
return o !== null && o !== void 0 && typeof o.then === 'function';
}
narrow-duck) Adopt some new mechanism, like a funny property name or unique symbol that must be made visible on all things that wish to be considered thenables. The intent is not to avoid duck typing entirely, but to avoid accidental collisions, especially with those who already have unrelated "then" methods.
Aesthetically, I prefer narrow-duck, just like a prefer a language without
__proto__. But for the same reason I pushed for __proto__, I feel I must
push for compat-duck.
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller <erights at google.com> wrote:
This is an example of what I am worried about. Another is
Object.create(p, {value: Promise}).Promise(....)where p is a promise.
I'm not quite sure what this is supposed to do, because it's invalid Object.create. (Or rather, it creates a property named "value" with default descriptors, which I'm sure isn't intended.)
Perhaps it would help if, when we start to think "people can fool you with..." it would help to substitute "an attacker can fool you with...".
What exactly is the attack scenario being envisioned here, though?
Okay, you can call a function and supply your own this value. And?
You can always do this, before or after construction. I don't think
this lets you fool anything, because you, the attacker, have to run
your own code to make it happen. You can't somehow trick the defender
into creating a tricky not-quite-authentic Promise, unless you've
tricked them into using eval() or something. If the attacker is
getting to run code of its choosing, you've already lost.
Am I missing some obvious attack?
On Wed, Aug 21, 2013 at 10:22 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
I'm not quite sure what this is supposed to do, because it's invalid Object.create. (Or rather, it creates a property named "value" with default descriptors, which I'm sure isn't intended.)
You're right, my code is wrong. What I meant is:
Object.create(p, {Promise: {value: Promise}}).Promise(....)
In other words, the Promise constructor might get supplied as its "this" an object that passes "p instanceof Promise" for innocent reasons other that "new" or .call. The question is, what does the Promise constructor test in order to determine whether it should use its coercion behavior or constructor behavior. If the test were "p instanceof Promise", then the above call, which was clearly intending to invoke its coercion behavior, would accidentally invoke its constructor behavior instead.
Perhaps it would help if, when we start to think "people can fool you with..." it would help to substitute "an attacker can fool you with...".
What exactly is the attack scenario being envisioned here, though?
The promise constructor must create initialize and return trustworthy promises, and it must not mark as trustworthy a promise that isn't. The promise coercer must return trustworthy promises. If given an object returned by the promise constructor or the promise coercer, the promise coercer must return that object.
Okay, you can call a function and supply your own
thisvalue. And? You can always do this, before or after construction.
If we weren't trying to put both coercing and constructing behavior into one function, switched on some unreliable test, then there wouldn't be a new problem. Postponing subclassing till ES6 when we have the needed support, the Promise constructor could just create and return a new trustworthy promise (just as the first branch of the "solution" I present below does). Promise.as would simply be the conditional we discussed earlier (and corresponds to the second branch of the "solution" below). But if we put these two behaviors in one function, what test do we use to choose between them?
I don't think this lets you fool anything, because you, the attacker, have to run your own code to make it happen.
The attacker does run their own code.
You can't somehow trick the defender into creating a tricky not-quite-authentic Promise, unless you've tricked them into using eval() or something. If the attacker is getting to run code of its choosing, you've already lost.
Uh, Tab, attackers always run code of their choosing. But they don't run that code with authority of their choosing. In an ocap system like SES, "eval" provides no authorities by default. See theory.stanford.edu/~ataly/Papers/sp11.pdf, erights.org/talks/thesis/markm-thesis.pdf Part II, research.google.com/pubs/pub40673.html section 2.3, and the "video" and "slides" links at mobicrant-talks.eventbrite.com
Am I missing some obvious attack?
Obvious perhaps only if you've been thinking about this kind of thing. Please have a look at those links.
In any case, postponing subclassing till ES6 when we have the needed support, I think I know how to "solve" the problem. It is a bit weird.
var Promise = (function(){
"use strict"; // of course
var brand = new WeakMap();
// only ever called with "new"
function HiddenPromiseConstructor(callback) {
// initialize "this", which it can assume starts fresh and trustworthily uninitialized
brand.set(this, true);
}
function Promise(arg) {
if (Object.getPrototypeOf(this) === Promise.prototype && !(brand.has(this))) {
// assume likely called with "new", but do not trust "this"
return new HiddenPromiseConstructor(arg)
} else {
// assume called for coercion behavior. Ignore this
if (brand.has(arg)) {
return arg;
} else {
return Promise.of(arg);
}
}
}
HiddenPromiseConstructor.prototype = Promise.prototype;
// initialize Promise.prototype
// initialize Promise statics
return Promise
})();
Btw, the problem this code illustrates is a problem Brendan pointed out to me at the last TC39 meeting.
On Thu, Aug 22, 2013 at 8:04 AM, Mark S. Miller <erights at google.com> wrote:
In other words, the Promise constructor might get supplied as its "this" an object that passes "p instanceof Promise" for innocent reasons other that "new" or .call. The question is, what does the Promise constructor test in order to determine whether it should use its coercion behavior or constructor behavior. If the test were "p instanceof Promise", then the above call, which was clearly intending to invoke its coercion behavior, would accidentally invoke its constructor behavior instead.
Okay, that's still defending a user from themselves, but whatever, I'm fine with that.
In any case, postponing subclassing till ES6 when we have the needed support, I think I know how to "solve" the problem. It is a bit weird.
There's an even easier method. Using "new" doesn't do anything
magical, it just sets this to be a fresh object with the right
proto. We can do that ourselves, and you can return whatever object
you want from the constructor, so you can avoid the
HiddenPromiseConstructor by just using an Object.create() call:
var self = Object.create(Promise.prototype);
Put that at the top of your constructor code, and return it at the
end, rather than this. Use whatever method you feel like for
determining that you were called as a constructor.
Otherwise, yeah, your code is how to do it, until we get the ability to specifically respond to being called vs being constructed.
I'd make one small change to this:
if (Object.getPrototypeOf(this) === Promise.prototype && !(brand.has(this))) {
to
if (this instanceof Promise && !(brand.has(this))) {
or an alternative that I think is functionally identical, if you want to avoid instanceof:
if (Promise.prototype.isPrototypeOf(this) && !(brand.has(this))) {
This change would allow subclassing of Promise.
On Thu, Aug 22, 2013 at 9:13 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
There's an even easier method. Using "new" doesn't do anything magical, it just sets
thisto be a fresh object with the right proto. We can do that ourselves, and you can return whatever object you want from the constructor, so you can avoid the HiddenPromiseConstructor by just using an Object.create() call:var self = Object.create(Promise.prototype);Put that at the top of your constructor code, and return it at the end, rather than
this.
Yes, this is equivalent to the HiddenPromiseConstructor approach.
Use whatever method you feel like for determining that you were called as a constructor.
What test to use for this determination was the entire question!
Otherwise, yeah, your code is how to do it, until we get the ability to specifically respond to being called vs being constructed.
Ok, I think we have our ES5 polyfill.
On Thu, Aug 22, 2013 at 9:22 AM, Brandon Benvie <bbenvie at mozilla.com> wrote:
I'd make one small change to this:
if (Object.getPrototypeOf(this) === Promise.prototype && !(brand.has(this))) {to
if (this instanceof Promise && !(brand.has(this))) {or an alternative that I think is functionally identical, if you want to avoid instanceof:
if (Promise.prototype.isPrototypeOf(this) && !(brand.has(this))) {This change would allow subclassing of Promise.
This change would mislead my example
Object.create(p, {Promise: {value: Promise}}).Promise(....)
into calling Promise's construct behavior instead of its coerce behavior.
On Thu, Aug 22, 2013 at 9:24 AM, Mark S. Miller <erights at google.com> wrote:
Use whatever method you feel like for determining that you were called as a constructor.
What test to use for this determination was the entire question!
Not really - that was only important if passing the test meant we
used the this object directly. If the test is just used to tell if
we were called as a constructor or converter, and we always produce a
fresh object in the constructor case, it's less important. You want
accuracy, of course, but it's not deathly important that we get things
precisely right. I trust whoever's writing the spec to define
something sensible. ^_^
I don't think you'll want to have divergent behavior for construct vs. call with new APIs. I believe that would go against Allen's approach for new ES6 built in classes, and beyond that, it unnecessarily overloads the API surface. Different operations ought to have different names.
Kevin Smith wrote:
I don't think you'll want to have divergent behavior for construct vs. call with new APIs. I believe that would go against Allen's approach for new ES6 built in classes, and beyond that, it unnecessarily overloads the API surface. Different operations ought to have different names.
+1.
Date is just a botch.
Boolean, Number, and String are legacy special cases, not to be imitated by Promise (not a value type coercer when called, primitive wrapper object constructor when new'ed).
What do we think of having "from" be the coercer? By which I mean, change Array.from to return its input if given a true Array (or properly-subclassed one with [[ArrayInitialisationState]] set to true, maybe??). Then Promise.from could follow that semantic, returning the input if it's a true promise or coercing it otherwise.
I can't see how this would hurt Array.from's use-case, which is usually going to be something like Array.from(arrayLike).forEach(…). And it fits the use case promises want perfectly.
The existing Array.from also copies the array-like, even if it is an array. Clearly such a copying operation is useful. Whether this should be bundled into Array.from, and whether .from is the right name if it is, are valid questions.
However, my first reaction is, leave Array.from alone. It is not a coercer, it is a copier. If we are agreed not to have the Promise constructor double as the coercer (which is fine with me), then I think the coercer should be called Promise.as. Besides subjective esthetics, I'm going to add a seemingly silly "user interface" consideration: Promise.from is longer than Promise.of. For the .then-level user, they seem identical -- they have no observable difference. However Promise.from imposes a hidden storage costs which we'd like the .then-level user to avoid paying, but brevity will lead them to make the wrong choice. Promise() and Promise.as are no longer than Promise.of, and so will not lead .then-level users astray.
If we do call the coercer Promise.from, as should rename the acceptor Promise.accept rather than Promise.of. If we want an Array coercer rather than an Array copier, we should consider renaming Array.from to Array.as.
Although seemingly silly, I actually make the above argument in all seriousness. As Brendan says "notation is user interface." In user interface design, path-of-least-resistance matters.
On Mon, Aug 26, 2013 at 7:47 AM, Mark Miller <erights at gmail.com> wrote:
If we do call the coercer Promise.from, as should rename the acceptor Promise.accept rather than Promise.of. If we want an Array coercer rather than an Array copier, we should consider renaming Array.from to Array.as.
I oppose naming the "just wrap it in a promise" operation to .accept()
- it has identical semantics to the existing Array#of(), because they're both monadic lifters, and the op should be named generically enough to work for more than just these two monads as well.
Although seemingly silly, I actually make the above argument in all seriousness. As Brendan says "notation is user interface." In user interface design, path-of-least-resistance matters.
I agree that naming is important. I'm fine with whatever here.
In esdiscuss/2013-August/032724 (plus following errata) I created the following promise:
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:
Promise.fulfill, and of course also thefulfilloption to the promise initializer.flatMapto operate on resolved values, so thatPromise.resolve(foreverPending).flatMap(x => assert(x === foreverPending))works.This removes the "accepted" state entirely. It means
flatMapeffectively 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 withthen. The current asymmetric choice ofnew Promise(({ resolve, reject, fulfill }) => ...)has always felt unfortunate to me.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.