Promise.cast and Promise.resolve

classic Classic list List threaded Threaded
128 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Promise.cast and Promise.resolve

Paolo Amadini
I have a suggestion about the current draft of the Promises
specification that derives from my experience on the Mozilla code base.
I'm not familiar with how the specification process works, discussion
in this group seemed like a good start.

Those familiar with the subject may find that this topic has already
been discussed (see [1] and [2]), but I think I may provide some
additional data that has not been previously examined, at least
according to the discussions that I found online, and may help in
determining the final direction.

In our code base, historically we only defined the "Promise.resolve"
function. I had a look at its 490 uses:
http://mxr.mozilla.org/mozilla-central/search?string=Promise.resolve

It looks like 487 of them don't have a promise as an argument, in which
case "cast" and "resolve" would behave in exactly the same way.

In the remaining cases (namely Task.jsm and AsyncShutdown.jsm) I
suspect we would always use either "resolve" (to be safe) or "cast"
(to be more efficient), and I'd lean for "cast" since we'd like Task
iterations to be faster. It also appears that "cast" has been selected
as the implicit conversion for Promise.all([valueOrPromise]) and
Promise.race([valueOrPromise]), maybe for the same efficiency reason.

Moreover, only after I read Domenic's comment [3] I realized that,
despite the name, the function that makes _less_ guarantees about the
returned object is "cast", and "resolve" actually made more guarantees.

So, if you're really interested in casting an "unsafe" promise to the
type of your promise library, it's theoretically better to use
"resolve" than "cast". By "unsafe" I mean a promise created internally
that may have been modified. In the case of "foreign" promises from
other libraries, using "cast" and "resolve" is again exactly the same
thing.

My take is that the difference between "cast" and "resolve" is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).

In the case of non-promises, where the behavior is really identical,
I expect that, with both functions available, by now in the Mozilla
code base we would have about 50% calls to "cast" and 50% calls to
"resolve". This, unless we spent time in defining a guideline for one
function or the other, with the associated education costs.

Assuming we succeeded in defining the guideline of always using "cast"
for non-promises, we'd have 490 calls to "cast" and no calls to
"resolve" at all. I also don't see a real-world use case for "resolve"
in the future. In case we needed to be really sure about the object
we're handling (that I don't think will be needed), I think we could
always use "new Promise(r => r(otherPromise))" instead.

My conclusion is that the "resolve" function could be removed.

Optionally, "cast" could be renamed to "resolve". It has in fact been
mentioned in [2] that some promise libraries already implement an
optimized "resolve", that works mostly like "cast". Against this
suggestion, there were concerns about the length of the name and
establishing a precedent for the name "cast".

I don't think the name is really important, but I'd rather not have
two almost identical functions to be chosen that will require a style
guideline and maybe another lint tool check to be defined in addition
to the ones that JavaScript already requires.

What do you think?

Regards,
Paolo

[1] https://github.com/domenic/promises-unwrapping/issues/86
[2] https://github.com/domenic/promises-unwrapping/issues/8
[3]
https://github.com/domenic/promises-unwrapping/issues/86#issuecomment-30066102
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Kevin Smith

My take is that the difference between "cast" and "resolve" is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).

Note that `Promise.resolve(p)`, where p is a promise, does *not* return an eventual for the eventual value of p.  Rather, it returns an eventual for p, literally.  Promises should be considered fully parametric (in other words, nestable).

If you want to convert a maybe-promise into a promise, then you want `cast`.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Juan Ignacio Dopazo-2
On Tuesday, January 28, 2014 10:13 AM, Kevin Smith <[hidden email]> wrote:

My take is that the difference between "cast" and "resolve" is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).


Note that `Promise.resolve(p)`, where p is a promise, does *not* return an eventual for the eventual value of p.  Rather, it returns an eventual for p, literally.  Promises should be considered fully parametric (in other words, nestable).

That's not true as per the last consensus. There was `Promise.fulfill(p)` which would've nested promises, but it was left for ES7 to investigate fulfill+flatMap.

Juan


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Kevin Smith

That's not true as per the last consensus. There was `Promise.fulfill(p)` which would've nested promises, but it was left for ES7 to investigate fulfill+flatMap.


I don't think that statement is correct.  Domenic, Allen, Mark, can we get a ruling? : )



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promise.cast and Promise.resolve

Domenic Denicola-2
I am hesitant to retread, but I suppose we should clear up the confusion of the last few messages.

Indeed, things evolved slightly since the last consensus, to the point where the solution that made the most sense was to store the promise's resolution value (whatever it may be) then do the unwrapping entirely inside `then`. So effectively, `Promise.resolve` is now what `Promise.fulfill` used to be; however, because `then` unwraps, in practice `then` users will not notice a difference (i.e. promises for promises are not observable). ES7-timeframe monad additions to the standard library could indeed make use of the stored resolution value.

To bring things down to earth more:

The following code will retain GC references to all of the variables, including `p2`, `p3`, and `p4`:

```js
var p1 = Promise.cast(1);
var p2 = Promise.resolve(gcRoot.p1);
var p3 = Promise.resolve(p2);
gcRoot.p4 = Promise.resolve(p3);
```

`gcRoot.p4` maintains a reference to `p3`, which maintains a reference to `p2`, which maintains a reference to `p1`.

Whereas, given

```js
var p1 = Promise.cast(1);
var p2 = Promise.cast(gcRoot.p1);
var p3 = Promise.cast(p2);
gcRoot.p4 = Promise.cast(p3);
```

we have that all the variables are equal, i.e. `p1 === p2`, `p2 === p3`, and `p3 === gcRoot.p4`.

---

With all that said, I somewhat agree with the sentiment of the OP that `Promise.resolve` is pointless, and even (from a memory consumption POV), a footgun. However, we settled on keeping it, based on a few weak arguments:

- Symmetry with `Promise.reject(r)` ≈ `new Promise((resolve, reject) => reject(r))`; we should also have `Promise.resolve(x)` ≈ `new Promise((resolve, reject) => resolve(x))`.
- Sometimes you want to guarantee object non-identity so a shorthand is useful (Tab Atkins had some use case involving CSS specs).

You can peruse the issue tracker for more discussion. We're certainly retreading old ground here.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Mark S. Miller-2
In reply to this post by Juan Ignacio Dopazo-2
First, "q = Promise.fulfill(p)" never made any sense, as if p is pending, then q cannot be fulfilled -- there's no non-promise value to fulfill it to. Remember, a promise is fulfilled when it's (original) .then would invoke its first (onFulfilled) callback. "fulfilled", "rejected", "pending" are at the .then level of abstraction.

At the .flatMap level of abstraction, the fulfill-like concept is "accept". Promise q accepts value (whether promise or non-promise) v when q's (original) .flatMap would invoke its first (onAccept) callback. "accept" is fully parametric, at the .flatMap level of abstraction, where "fully parametric" is meaningful.

So, except for the name of the old operation we're no longer using, I agree with Domenic. It is not that we renamed "Promise.fulfill" to "Promise.resolve", we killed "Promise.fulfill" because it was incoherent, and we renamed "Promise.accept" to "Promise.resolve". 

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.



On Tue, Jan 28, 2014 at 10:20 AM, Juan Ignacio Dopazo <[hidden email]> wrote:
On Tuesday, January 28, 2014 10:13 AM, Kevin Smith <[hidden email]> wrote:

My take is that the difference between "cast" and "resolve" is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).


Note that `Promise.resolve(p)`, where p is a promise, does *not* return an eventual for the eventual value of p.  Rather, it returns an eventual for p, literally.  Promises should be considered fully parametric (in other words, nestable).

That's not true as per the last consensus. There was `Promise.fulfill(p)` which would've nested promises, but it was left for ES7 to investigate fulfill+flatMap.

Juan


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Paolo Amadini
[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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Quildreen Motta
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
--
Quildreen "(Soreλ\a)" Motta  (http://robotlolita.github.io/)
— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

FW: Promise.cast and Promise.resolve

Forbes Lindesay
In reply to this post by Mark S. Miller-2

This accidentally ended up not being forwarded to the list

 

From: Mark S. Miller [mailto:[hidden email]]
Sent: 28 January 2014 19:52
To: Forbes Lindesay
Subject: Re: Promise.cast and Promise.resolve

 

That has always been my preference as well. But given the current stage things are in, is it worth fighting to remove it? If you feel it is, please repost your objection to es-discuss or promises-unwrapping.

 

On Tue, Jan 28, 2014 at 11:44 AM, Forbes Lindesay <[hidden email]> wrote:

It seems that the use case of `Promise.resolve` is to allow you to create a Promise for a Promise.  It seems to me that we should wait until it observable before we define a method for creating it.  I feel like we’re going about things backwards at the moment.  We can commit to discussing Promises for Promises later, but if we add this now it's as if we're committing to actually having Promises for Promises.

I'm definitely in favour of removing `Promise.resolve`.



 

--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Brendan Eich-3
In reply to this post by Quildreen Motta
Quildreen Motta wrote:
> 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.

IIRC (and I may not; endless promises threads make me sleepy) this is
the reason to have Promise.resolve: to enable some to blaze the flatMap
trail ahead of ES6.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Promise.cast and Promise.resolve

Domenic Denicola-2
From: es-discuss <[hidden email]> on behalf of Brendan Eich <[hidden email]>

> Quildreen Motta wrote:
>> 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.
>
> IIRC (and I may not; endless promises threads make me sleepy) this is the reason to have Promise.resolve: to enable some to blaze the flatMap trail ahead of ES6.

Kind of. Since `Promise.resolve(x)` is just `new Promise(resolve => resolve(x))`, the only reasons for including that shorthand method are symmetry and the idea that this operation might be common enough to necessitate a shorthand. See my earlier reply.

On the other hand, that *is* part of the reason we moved all the unwrapping to the `then` side---as Mark puts it, using the "accept" operation instead of "resolve," albeit while still using the "resolve" name. (Which is pretty confusing when you try to explain it, but I swear, it makes sense...)
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Brendan Eich-3
Domenic Denicola wrote:

> From: es-discuss<[hidden email]>  on behalf of Brendan Eich<[hidden email]>
>
>> >  Quildreen Motta wrote:
>>> >>  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.
>> >
>> >  IIRC (and I may not; endless promises threads make me sleepy) this is the reason to have Promise.resolve: to enable some to blaze the flatMap trail ahead of ES6.
>
> Kind of. Since `Promise.resolve(x)` is just `new Promise(resolve =>  resolve(x))`, the only reasons for including that shorthand method are symmetry and the idea that this operation might be common enough to necessitate a shorthand. See my earlier reply.
>
> On the other hand, that*is*  part of the reason we moved all the unwrapping to the `then` side---as Mark puts it, using the "accept" operation instead of "resolve," albeit while still using the "resolve" name. (Which is pretty confusing when you try to explain it, but I swear, it makes sense...)

I buy it.

Paolo may not. Mozilla XUL JS does seem full of .resolve calls, some of
which might want to be .cast calls instead.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Andreas Rossberg-4
In reply to this post by Quildreen Motta
On 28 January 2014 21:21, Quildreen Motta <[hidden email]> wrote:

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

This type is not really accurate. Due to recursive unwrapping, `then'
has no type you could express in any reasonable type system -- the
argument type can be an arbitrary tower of nested promises (and the
maximum one for each use). As you note below, this makes the operation
inherently non-parametric. (Which is why I still hold up that
recursive unwrapping is a bad idea, especially as the core primitive.)

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

The V8 implementation provides it under the name `chain', with the
obvious semantics.

/Andreas


> On 28 January 2014 18:07, Paolo Amadini <[hidden email]> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> --
> Quildreen "(Soreλ\a)" Motta  (http://robotlolita.github.io/)
> — JavaScript Alchemist / Minimalist Designer / PLT hobbyist —
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Brendan Eich-3
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

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Andreas Rossberg-4
On 29 January 2014 00:30, Brendan Eich <[hidden email]> 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 does not have flatMap. Scala has.

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Brendan Eich-3
Andreas Rossberg wrote:

> On 29 January 2014 00:30, Brendan Eich<[hidden email]>  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 does not have flatMap. Scala has.

What's all this then?

https://www.google.com/search?q=haskell+flatmap

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Quildreen Motta
In reply to this post by Andreas Rossberg-4

On 28 January 2014 21:27, Andreas Rossberg <[hidden email]> wrote:
On 28 January 2014 21:21, Quildreen Motta <[hidden email]> wrote: 

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

The V8 implementation provides it under the name `chain', with the
obvious semantics.

Considering that the fantasy-land specification uses the `chain` name as well, this is really neat.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Forrest L Norvell
In reply to this post by Brendan Eich-3
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 theory in which monads are a specialization of applicative functors only came later. Rationalizing all of that would require breaking backwards compatibility of most Haskell code that depends on the standard library. Scala wasn't stuck with this legacy, so they kept the more general term for the operation.

'chain' is a fine name, especially because "monadic promises" work fine in a language with type systems, but the JS version, when / if it comes, is only going to be a distantly rhyming version of a monad, for reasons that we've gone over to death in the past. JS should give names to operations that will actually give people a clue to their purpose.



On Tue, Jan 28, 2014 at 3:48 PM, Brendan Eich <[hidden email]> wrote:
Andreas Rossberg wrote:
On 29 January 2014 00:30, Brendan Eich<[hidden email]>  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 does not have flatMap. Scala has.

What's all this then?

https://www.google.com/search?q=haskell+flatmap

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Andreas Rossberg-4
In reply to this post by Brendan Eich-3
On 29 January 2014 00:48, Brendan Eich <[hidden email]> wrote:

> Andreas Rossberg wrote:
>>
>> On 29 January 2014 00:30, Brendan Eich<[hidden email]>  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 does not have flatMap. Scala has.
>
> What's all this then?
>
> https://www.google.com/search?q=haskell+flatmap

When the first page of results consists of StackOverflow questions and
blog posts it can't be real. :)

Seriously, Haskell calls it >>=. (It also has concatMap, which is just
the same function restricted to lists.)

/Andreas
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Promise.cast and Promise.resolve

Brendan Eich-3
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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234 ... 7