On Fri, May 10, 2013 at 2:04 PM, Mark S. Miller <erights at google.com> 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

> I did not intend to start a fight

I didn't intend to start a fight either.  ^_^  I just wanted to make sure no one was arguing against strawmen.

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