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 <[email protected]> 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 > [email protected] > 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 —*
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
