Re: Promise.cast and Promise.resolve

On 29 January 2014 00:30, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: `flatMap` ... The V8 implementation provides it under the name `chain', with the obvious semantics. +1 on chain as name, not flatMap, but Haskell'ers should weigh in. Wait, no. :-P Well, Haskell

Re: Promise.cast and Promise.resolve

Andreas Rossberg wrote: On 29 January 2014 00:30, Brendan Eichbren...@mozilla.com wrote: Andreas Rossberg wrote: `flatMap` ... The V8 implementation provides it under the name `chain', with the obvious semantics. +1 on chain as name, not flatMap, but Haskell'ers should weigh

Re: Promise.cast and Promise.resolve

On 28 January 2014 21:27, Andreas Rossberg rossb...@google.com wrote: On 28 January 2014 21:21, Quildreen Motta quildr...@gmail.com wrote: But later, once `flatMap` is introduced, you'll be able to deal with nested promises without breaking parametricity: Promise.flatMap ::

Re: Promise.cast and Promise.resolve

In Haskell, 'flatMap' is the operation on applicative functors that corresponds to the 'bind' operation on monads. Monads were introduced to Haskell to provide a mechanism for doing effectful programming that restricted the areas of danger around I/O, and the reification of the underlying category

Re: Promise.cast and Promise.resolve

On 29 January 2014 00:48, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: On 29 January 2014 00:30, Brendan Eichbren...@mozilla.com wrote: Andreas Rossberg wrote: `flatMap` ... The V8 implementation provides it under the name `chain', with the obvious

Re: Promise.cast and Promise.resolve

Andreas Rossberg wrote: Seriously, Haskell calls it=. Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it pronounced b-i-n-d always, monads or not? (It also has concatMap, which is just the same function restricted to lists.) Rhyming. /be

Re: Promise.cast and Promise.resolve

The V8 implementation provides it under the name `chain', with the obvious semantics. I like chain too, and the V8 implementation in general. However, note that the V8 implementation does not comply with the current spec. According to the current spec, the *output* side of `then` is

Re: Promise.cast and Promise.resolve

On Tue, Jan 28, 2014 at 7:47 PM, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: Seriously, Haskell calls it=. Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it pronounced b-i-n-d always, monads or not? No, it's always called bind in Haskell. The

Re: Promise.cast and Promise.resolve

On 29 January 2014 01:27, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Tue, Jan 28, 2014 at 7:47 PM, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: Seriously, Haskell calls it=. Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it

Re: Promise.cast and Promise.resolve

Quildreen Motta wrote: I suppose using names that don't give you a hint of the meaning of the operation fits perfectly Haskell's (and Scalaz's) Avoid Success At All Costs tradition lulz. And so we will go with 'chain'. /be ___ es-discuss mailing

Re: Promise.cast and Promise.resolve

In this case, a half pursuit of type purity is a side quest at the expense of users. Having two ways to resolve and two ways to observe a promise is unnecessarily confusing. In my experience, one method like then, that unwraps recursively, and one function, like Promise.cast, that automatically

Re: Promise.cast and Promise.resolve

This seems like something that can be deferred to ES7. On Tue, Jan 28, 2014 at 8:12 PM, Kris Kowal kris.ko...@cixar.com wrote: In this case, a half pursuit of type purity is a side quest at the expense of users. Having two ways to resolve and two ways to observe a promise is unnecessarily

Re: Promise.cast and Promise.resolve

But, I would pick one or the other over one with multiple personalities This is a good mentality to have. Consider picking the one that allows the other one to be implemented in user land. This would allow both parties to benefit from the integrated tooling performance boosts of it being a

Re: Promise.cast and Promise.resolve

Kris Kowal wrote: I would pick Promise.cast and then, let complexity melt off the spec, and stop worrying. Seems not everyone agrees, especially since Promise.resolve is all over the place. I wonder with task.js like solutions whether we'll actually have lots of hand-.then'ing of promises.

Re: Promise.cast and Promise.resolve

Ryan Scheel wrote: This seems like something that can be deferred to ES7. Which this? .chain is deferred to ES7, and in V8 experimentally. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Promise.cast and Promise.resolve

Auto-lifting/unwrapping promises are beautiful. Purely monadic promises are beautifully captured by type theory. But, I would pick one or the other over one with multiple personalities. I would pick Promise.cast and then, let complexity melt off the spec, and stop worrying. AP2 might not

Re: Promise.cast and Promise.resolve

This seems like something that can be deferred to ES7. Which this? .chain is deferred to ES7, and in V8 experimentally. Deferring `chain` is, if not future-hostile to `chain`, then future-irritant. The way Promises are currently spec'd, the return value of the `then` callback is itself

Re: Promise.cast and Promise.resolve

On Jan 28, 2014, at 10:14 PM, Kevin Smith zenpars...@gmail.com wrote: This seems like something that can be deferred to ES7. Which this? .chain is deferred to ES7, and in V8 experimentally. Deferring `chain` is, if not future-hostile to `chain`, then future-irritant. The way

<    1   2