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