So, if I understand correctly, it basically boils down to:

Promise.resolve :: a → Promise(a)

Promise.cast :: a → Promise(a)
Promise.cast :: Promise(a) → Promise(a)

But right now we'll only get `.then`, so transformations with nested
promises will flatMap automatically:

Promise.then :: (Promise(a)) => ((a → MaybePromise(b), (a → MaybePromise(b))
Promise.then :: (Promise(Promise(a))) => ((a → MaybePromise(b), (a →
MaybePromise(b))

But later, once `flatMap` is introduced, you'll be able to deal with nested
promises without breaking parametricity:

Promise.flatMap :: (Promise(a)) => (a → Promise(b))

If that's correct, I don't see any use cases for Promise.resolve right now,
unless a library where to provide a corresponding unspecified `flatMap`
implementation.


On 28 January 2014 18:07, Paolo Amadini <paolo.02.prg at amadzone.org> wrote:

> [Replying here since I'm not sure about how to move the discussion to
> the issue tracker without losing the context of Mark's observation.]
>
> On 28/01/2014 20.28, Mark S. Miller wrote:
> > For people concerned only about the .then level of abstraction, I see
> > little reason to ever use Promise.resolve rather than Promise.cast, and
> > much reason to prefer Promise.cast. But fwiw we did agree to express the
> > difference now, to be perceived by future and experimental uses of
> > .flatMap in the future.
>
> I don't have a background on the .flatMap level of abstraction. In the
> following scenario, will users of getMyPromise() have a different
> behavior with .flatMap if the library code used "cast" rather than
> "resolve"? If so, this can definitely lead to confusion when .flatMap
> is introduced in the future since the callers cannot be sure about
> what the library did internally, assuming the library authors didn't
> intentionally choose one or the other.
>
> ```js
> // ------ MyLibrary.js
>
> function getMyPromise() {
>   var a = condition ? getMyOtherPromise() : "value2";
>   return Promise.resolve(a);
> }
>
> function getMyOtherPromise() {
>   return Promise.resolve("value1");
> }
> ```
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
--
Quildreen "(Soreλ\a)" Motta
(http://robotlolita.github.io/<http://killdream.github.com/>
)
*— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140128/f732753e/attachment.html>

So, if I understand correctly, it basically boils down to:

```
Promise.resolve :: a → Promise(a)

Promise.cast :: a → Promise(a)
Promise.cast :: Promise(a) → Promise(a)
```

But right now we'll only get `.then`, so transformations with nested
promises will flatMap automatically:

```
Promise.then :: (Promise(a)) => ((a → MaybePromise(b), (a → MaybePromise(b))

Promise.then :: (Promise(Promise(a))) => ((a → MaybePromise(b), (a → MaybePromise(b))
```

But later, once `flatMap` is introduced, you'll be able to deal with nested
promises without breaking parametricity:

```
Promise.flatMap :: (Promise(a)) => (a → Promise(b))
```

If that's correct, I don't see any use cases for Promise.resolve right now,
unless a library where to provide a corresponding unspecified `flatMap`
implementation.