On Fri, May 10, 2013 at 2:04 PM, Mark S. Miller <[email protected]> wrote: > Hi Tab, I did not intend to start a fight with you over the term "monadic > promises".
I didn't intend to start a fight either. ^_^ I just wanted to make sure no one was arguing against strawmen. > 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. I don't think we need to refer to "unabashed monadic promises" (your #1) at all - nobody's seriously defending them, and they're far from Promises/A+. It's trivial to add map() and flatMap() to promises if you want them, but .then() functions as a perfectly fine flatMap() already if you maintain type discipline yourself. The only serious proposals seem to be "Q-like promises", which explicitly prevent nested promises by auto-flattening when necessary, and "monadic promises", which allow nested promises if you explicitly ask for it (but the flattening semantics ensure that it's hard to accidentally fall into a nested case). ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
