The fact that we can make it monadic is just a bonus; any time you see
monad just think container++ - it's just a proven useful bit of
structure on top which makes it easy to work with the values inside
the container. (It's a bit more abstract than that, of course, but
thinking in terms of
On Thu, May 30, 2013 at 6:15 AM, Claus Reinke claus.rei...@talk21.com wrote:
The fact that we can make it monadic is just a bonus; any time you see
monad just think container++ - it's just a proven useful bit of
structure on top which makes it easy to work with the values inside
the container.
On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
russell.legg...@gmail.com wrote:
On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
On Tue, May 28, 2013 at 12:24 PM, Russell Leggett russell.legg...@gmail.com
wrote:
On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
russell.legg...@gmail.com wrote:
On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr.
I'm not arguing 'chain' be removed. I'm convinced at this point its worth
including, I'm just debating the method name here. Sorry if it's just
bikeshedding at this point, but on the face of it, the two methods seem
hard to distinguish, and while 'chain' might be a better name for some
2013/5/26 Brendan Eich bren...@mozilla.com
Russell Leggett wrote:
I'm sorry if I have just missed it trying to keep up to date, but what
are the compelling use cases.
AsyncTable with promises as values.
What the discussion at last week's TC39 meeting clarified for me is the
following:
-
And to add why auto-unwrapping is the right thing to do when using
promises-for-control:
I think of promise/resolve as the async analog to function call/return.
In sequential programming, imagine a function f() that calls another
function g() and returns its result (i.e. the call to g() is a
On Sun, May 26, 2013 at 1:38 PM, Brendan Eich bren...@mozilla.com wrote:
Russell Leggett wrote:
I'm sorry if I have just missed it trying to keep up to date, but what
are the compelling use cases.
AsyncTable with promises as values.
No name mangling. I prefer then and chain. One more
On 27 May 2013 15:30, Tom Van Cutsem tomvc...@gmail.com wrote:
What the discussion at last week's TC39 meeting clarified for me is the
following:
- Promises are primarily a control-flow abstraction.
- Sometimes, they are also used as a data-abstraction (i.e. as a container
in their own
On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
russell.legg...@gmail.com wrote:
I'm just going to go ahead and play stupid here. Why is it called chain? I
agree one more method doesn't break anyone's brain, but I think the
confusion comes when it is not clear what a method is for and when
2013/5/27 Andreas Rossberg rossb...@google.com
On 27 May 2013 15:30, Tom Van Cutsem tomvc...@gmail.com wrote:
What the discussion at last week's TC39 meeting clarified for me is the
following:
- Promises are primarily a control-flow abstraction.
- Sometimes, they are also used as a
My apologies, I've seen three use cases. The third use case being the ability
to send progress notifications.
Sent from Windows Mail
From: Ron Buckton
Sent: Monday, May 27, 2013 12:47 PM
To: Andreas Rossberg, Tom Van Cutsem
Cc: Mark S. Miller, Brendan Eich, es-discuss
Are there a
On Sat, May 25, 2013 at 6:00 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
AP2 from Mark's slides:
AP2 (Based on Tab’s latest)
• Q.fulfill // lifting
• Q() // autolifting, resolve
• p.then // deep flattening
• p.flatMap // “chain”
Apologies for being a
On Fri, May 24, 2013 at 1:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
AP3 (recursive unwrapping of the return value of .then()) doesn't give
Q people the guarantees they want (.then() callbacks always receive a
plain value), nor does it give monadic people the flexibility they
want
On Sat, May 25, 2013 at 1:30 PM, Brendan Eich bren...@mozilla.com wrote:
Sam Tobin-Hochstadt wrote:
In the meeting, there were (a) people advocating for styles of
programming along the lines that you (Tab) have put forward, like me,
(b) people advocating for Q-style programming, like Mark,
Sam Tobin-Hochstadt wrote:
On Sat, May 25, 2013 at 1:30 PM, Brendan Eichbren...@mozilla.com wrote:
Sam Tobin-Hochstadt wrote:
In the meeting, there were (a) people advocating for styles of
programming along the lines that you (Tab) have put forward, like me,
(b) people advocating for Q-style
Tab Atkins Jr. wrote:
AP2 from Mark's slides:
AP2 (Based on Tab’s latest)
• Q.fulfill // lifting
• Q() // autolifting, resolve
• p.then // deep flattening
• p.flatMap // “chain”
Apologies for being a broken record, but just to make sure the detail
isn't lost in the noise...
AP2
On Thu, May 23, 2013 at 10:18 PM, Mark S. Miller erig...@google.com wrote:
I went into more depth on this matter in a presentation I just did at TC39.
The slide deck is at
http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Aconcurrencymedia=strawman:promisesvsmonads2.pdf.
It was written
Tab Atkins Jr. wrote:
What's more, if you're using .then() for things, but you're passing in
a callback from elsewhere that assumes it can return nested promises,
everything's still kosher! If you chain another .then() off of it,
you'll still get a plain value; if you chain a
On Fri, May 24, 2013 at 12:40 PM, Brendan Eich bren...@mozilla.com wrote:
Tab Atkins Jr. wrote:
What's more, if you're using .then() for things, but you're passing in
a callback from elsewhere that assumes it can return nested promises,
everything's still kosher! If you chain another .then()
Tab Atkins Jr. wrote:
Yeah, that's right, but like I keep saying, that means that thenable
promises and chainable promises are no longer interoperable without
ugly helpers - a chainable promise might stack promises (doing
{value:{value:{value:foo}}}), and if you call .then() on it, you end
up
Tab Atkins Jr. wrote:
Not to worry, no final ultimate double-checked decision was reached.;-)
Yeah, I know, but I've learned over time that influencing the
conversation early is useful. ^_^
Forgot to write: early? LOL, this past week's meeting was years *late*
in terms of promises
On Thu, May 23, 2013 at 6:19 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
The point of my post was to demonstrate that fulfill/chain aka unit/bind
could be built in user space *extremely simply*, thus allowing the nascent
monadic efforts in JS to go off and do their own thing for a
On Wed, May 22, 2013 at 9:31 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Thoughts?
Sounds like a great user-space library!!
You... you can't. You can't build .chain() on top of .then() in a way
that actually interoperates.
On Wed, May 22, 2013 at 10:19 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It also adds a fulfill method. Thus, it presents two interfaces to the user:
fulfill + chain (aka unit + bind), and Q + then (aka resolve + then). This
seems to squarely fall into the trap Mark described in
On Thu, May 23, 2013 at 6:57 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, May 22, 2013 at 10:19 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It also adds a fulfill method. Thus, it presents two interfaces to the
user: fulfill + chain (aka unit + bind), and Q + then (aka
I found it [a fun exercise](https://gist.github.com/domenic/5632079) to show
how little code it takes to build unabashed monadic promises on top of Q-like
promises. (It's been a while since I exercised those brain-muscles, so any
corrections appreciated.) The punch line is
```js
function
On Wed, May 22, 2013 at 6:04 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I found it [a fun exercise](https://gist.github.com/domenic/5632079) to show
how little code it takes to build unabashed monadic promises on top of Q-like
promises. (It's been a while since I exercised those
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Thoughts?
Sounds like a great user-space library!!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Tab’s proposal as I understand it is to standardize Q-like promises and add
a chain method that is then but with behavior tailored for monadic
composition.
This sounds like a good compromise.
The only downside I can contrive is that it gives users, particularly
novices, a subtle choice. Would it
It also adds a fulfill method. Thus, it presents two interfaces to the user:
fulfill + chain (aka unit + bind), and Q + then (aka resolve + then). This
seems to squarely fall into the trap Mark described in his original post, viz.
The main failure mode of standards bodies is to resolve a
[+es-discuss]
I didn't realize that I composed this in reply to a message only on
public-script-coord. Further discussion should occur only on es-discuss.
Sorry for the confusion.
On Fri, May 10, 2013 at 5:52 AM, Mark S. Miller erig...@google.com wrote:
I think the key exchange in these
On Fri, May 10, 2013 at 5:55 AM, Mark S. Miller erig...@google.com wrote:
[...]
This same abstraction in a Q-like promise system would be written
class AsyncTablet,u {
constructor() {
this.m = Mapt,u(); // encapsulation doesn't matter for this
example
}
On Fri, May 10, 2013 at 6:05 AM, Mark S. Miller erig...@google.com wrote:
On Fri, May 10, 2013 at 5:55 AM, Mark S. Miller erig...@google.comwrote:
[...]
This same abstraction in a Q-like promise system would be written
class AsyncTablet,u {
constructor() {
this.m
class AsyncTableT,U {
constructor() {
this.m = MapT,U(); // encapsulation doesn't matter for this
example
}
set(keyP :PromiseT, val :U) {
keyP.then(key = { this.m.set(key, val) });
}
get(keyP :PromiseT) :PromiseU {
On Fri, May 10, 2013 at 6:58 AM, Kevin Smith zenpars...@gmail.com wrote:
class AsyncTableT,U {
constructor() {
this.m = MapT,U(); // encapsulation doesn't matter for
this example
}
set(keyP :PromiseT, val :U) {
keyP.then(key = {
Le 10 mai 2013 à 14:55, Mark S. Miller erig...@google.com a écrit :
[+es-discuss]
I didn't realize that I composed this in reply to a message only on
public-script-coord. Further discussion should occur only on es-discuss.
Sorry for the confusion.
On Fri, May 10, 2013 at 5:52 AM,
] On
Behalf Of Claude Pache
Sent: Friday, May 10, 2013 11:25 AM
To: Mark S.Miller
Cc: public-script-co...@w3.org; es-discuss
Subject: Re: The Paradox of Partial Parametricity
Le 10 mai 2013 à 14:55, Mark S. Miller
erig...@google.commailto:erig...@google.com a écrit :
[+es-discuss]
I didn't realize
[+es-discuss]
On 10 May 2013 21:05, Andreas Rossberg rossb...@google.com wrote:
On 10 May 2013 14:52, Mark S. Miller erig...@google.com wrote:
An upper case type variable, e.g. T, is fully parametric. It may be a
promise or non-promise.
A lower case type variable, e.g. t, is constrained to be
[Forgot to pick up es-discuss in this message. _]
On Fri, May 10, 2013 at 11:42 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, May 10, 2013 at 5:52 AM, Mark S. Miller erig...@google.com wrote:
Together with each of their explanations about what they meant. They are
both right. Lifting
[dropping public-script-coord. Let's keep the discussion on es-discuss.
Apologies again on starting this thread with an email to the wrong list.]
On Fri, May 10, 2013 at 1:00 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
[Forgot to pick up es-discuss in this message. _]
On Fri, May 10, 2013
On Fri, May 10, 2013 at 2:04 PM, Mark S. Miller erig...@google.com wrote:
Hi Tab, I did not intend to start a fight with you over the term monadic
promises.
I didn't intend to start a fight either. ^_^ I just wanted to make
sure no one was arguing against strawmen.
Since we seem to be
On Fri, May 10, 2013 at 2:18 PM, Mark S. Miller erig...@google.com wrote:
Hi Tab, these are the three architectures I am trying to compare in order to
make a point. Since you don't like the labels I've chosen for them, please
suggest alternatives that should be clear and acceptable to all so
Fine. If there are no further objections, the three architectures are
Unabashed Monadic Promises
Q-Like Promises
Abashed Monadic Promises
On Fri, May 10, 2013 at 2:28 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, May 10, 2013 at 2:18 PM, Mark S. Miller erig...@google.com
wrote:
44 matches
Mail list logo
