A Challenge Problem for Promise Designers

Tab Atkins Jr. jackalmage at gmail.com
Sat Apr 27 09:54:10 PDT 2013

On Sat, Apr 27, 2013 at 9:48 AM, Mark Miller <erights at gmail.com> wrote:
> Cool. I think we (at least you and I) have agreement on default flattening
> (#0).

Yay for terminology confusion masquerading as disagreement!

> FWIW, the reason I'm surprised that you're calling this monadic is the need
> for the dynamic test on 'as long as "b" isn't a Promise'. In other words,
> the signature of .then (including the receiver and excluding the errback) is
> overloaded as
>    promise<a> -> (a -> promise<b>) -> promise<b>
> or
>    promise<a> -> (a -> b) -> promise<b> // when b is not itself a promise
> type
> My impression is that each of these overloads by itself is a different monad
> operation and that testing the condition in the comment violates
> parametricity. If these do correspond to two different monad operations,
> then different laws cover each. A similar analysis applies to Q(x) (aka
> Future.resolve(x)).
> In any case, no matter. We agree (assimilation aside) that this is how .then
> and Q should behave. Wonderful!

The reason this is still monadic is because, as long as you follow the
monad type requirements properly, passing a callback with signature "a
-> Promise<b>", it works as a monad.  No need for tests, no special
behavior, nothing.

It's just that we *also* mix in the functor behavior into .then(), so
that, if you fail to satisfy the monad type requirements, we can fall
back to treating it as a functor.  That's the second overload.  (It's
not monadic.)

(It might be nice to explicitly provide a .map() operation following
the functor laws, but it isn't very important to me.)

I'm fine with monadic operations that do additional things when you go
beyond the basic type contract, just like I'm fine with calling
Array.of() the monadic lift operator for Arrays - if called with one
value, as the monad contract requires, it lifts the value into an
array.  It can just *also* be called with 0 or 2+ arguments, and
that's fine.


More information about the es-discuss mailing list