2013/5/21 Andreas Rossberg rossb...@google.com
What's your definition of entirely transparent then? Or in other
words, what if I use 'promise' outside a when?
I clarified this with Andreas in person, but FTR: entirely transparent is
indeed the wrong word to describe E promises.
For context,
On 20 May 2013 14:15, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/4/26 Andreas Rossberg rossb...@google.com
I'm not sure if your description of E is accurate -- I'd find that
surprising. It _is_ a perfectly sensible design to have transparent
futures that you can just use in place of the
(catching up on old threads, sorry for the asynchrony [no puns intended
;-)])
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
I have read somewhere (I can't remember where, hopefully MarkM will
confirm
or say if I imagined it) that in E, if a variable contains a promise and
On 26 April 2013 17:58, Mark Miller erig...@gmail.com wrote:
I posed my challenge problem primarily as a response to Andreas' position.
Andreas, please rewrite the *very small* example in the linked-to paper
(Also at
https://code.google.com/p/es-lab/source/browse/trunk/src/ses/contract/) in
To: Mark Miller
Cc: David Sheets; Mark S. Miller; es-discuss; public-script-co...@w3.org; Ron
Buckton; David Bruant; Dean Tribble
Subject: Re: A Challenge Problem for Promise Designers
On Sat, Apr 27, 2013 at 5:46 PM, Mark Miller erig...@gmail.com wrote:
I am worried that we're again
On Mon, Apr 29, 2013 at 11:03 AM, Ron Buckton rbuck...@chronicles.org wrote:
Thanks for the clarifications re: Future as a monad. My understanding of this
is as follows (please correct me if I am wrong):
* The expected result of the resolve/reject callbacks passed to Future#then
is itself a
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Monday, April 29, 2013 11:21 AM
To: Ron Buckton
Cc: Mark Miller; David Sheets; Mark S. Miller; es-discuss; public-script-
co...@w3.org; David Bruant; Dean Tribble
Subject: Re: A Challenge Problem for Promise
On Mon, Apr 29, 2013 at 1:07 PM, Ron Buckton rbuck...@chronicles.org wrote:
I updated [1] my rough implementation of Future based on this discussion.
This has the following changes from the previous [2] version which was based
on the DOM spec for Future:
* The resolver's resolve algorithm
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Monday, April 29, 2013 1:20 PM
To: Ron Buckton
Cc: Mark Miller; David Sheets; Mark S. Miller; es-discuss; public-script-
co...@w3.org; David Bruant; Dean Tribble
Subject: Re: A Challenge Problem for Promise
On Fri, Apr 26, 2013 at 1:51 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to
actually provide
Here is a case where flattening helps:
function executeAndWaitForComplete(command) {
return getJSON(commandUrl + command)
.then(function (commandResult) {
if (commandResult.complete) {
return commandResult.model;
}
var statusUrl = commmandResult.statusUrl;
On Sat, Apr 27, 2013 at 7:38 AM, Mark Miller erig...@gmail.com wrote:
On Fri, Apr 26, 2013 at 1:51 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me:
On Sat, Apr 27, 2013 at 9:21 AM, Ron Buckton rbuck...@chronicles.org wrote:
Here is a case where flattening helps:
[snip example code]
In this example, the server will receive a command from the client and will
process it asynchronously. The client then needs to poll an endpoint to
check for
Cool. I think we (at least you and I) have agreement on default flattening
(#0).
FWIW, the reason I'm surprised that you're calling this monadic is the need
for the dynamic test on 'as long as b isn't a Promise'. In other words,
the signature of .then (including the receiver and excluding the
On Sat, Apr 27, 2013 at 9:48 AM, Mark Miller erig...@gmail.com wrote:
Cool. I think we (at least you and I) have agreement on default flattening
(#0).
Yay for terminology confusion masquerading as disagreement!
FWIW, the reason I'm surprised that you're calling this monadic is the need
for
On Sat, Apr 27, 2013 at 5:21 PM, Ron Buckton rbuck...@chronicles.org wrote:
Here is a case where flattening helps:
function executeAndWaitForComplete(command) {
return getJSON(commandUrl + command)
.then(function (commandResult) {
if (commandResult.complete) {
return
On Sat, Apr 27, 2013 at 9:55 AM, David Sheets kosmo...@gmail.com wrote:
[...]
I think the major point of confusion in these discussions is the
result of the framing of the discussion in terms of flattening. I
believe most beneficial viewpoint is that of autolifting.
That is, the exceptional
On Sat, Apr 27, 2013 at 10:05 AM, Mark S. Miller erig...@google.com wrote:
Are you distinguishing autolifting vs lifting? If so, why do you think
it is important or desirable to provide a lifting operation (as opposed to
an autolifting operation)?
Because the lifting operation is the monadic
Sorry, I've been writing code with E style promises for, jeez, over 20
years now. (I suddenly feel very old :( .) I don't remember ever
experiencing the failure you're talking about. Can you give a concrete
example?
On Sat, Apr 27, 2013 at 10:09 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On
On Sat, Apr 27, 2013 at 10:20 AM, Mark Miller erig...@gmail.com wrote:
Sorry, I've been writing code with E style promises for, jeez, over 20 years
now. (I suddenly feel very old :( .) I don't remember ever experiencing the
failure you're talking about. Can you give a concrete example?
E-style
On Fri, Apr 26, 2013 at 11:18 AM, Andreas Rossberg rossb...@google.comwrote:
On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote:
The fundamental controversy, as Juan just noted, is how to precisely
identify a promise in order to do either of these two things. This
problem
On Sat, Apr 27, 2013 at 2:21 PM, Dean Landolt d...@deanlandolt.com wrote:
On Fri, Apr 26, 2013 at 11:18 AM, Andreas Rossberg rossb...@google.com
wrote:
On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote:
The fundamental controversy, as Juan just noted, is how to precisely
I am worried that we're again separated by a common terminology more than
we are by an actual technical disagreement. I am arguing against an
unconditional lift operation that would make a promise-for-promise. Or at
least seeking to provoke someone to provide a compelling example showing
why this
On Sat, Apr 27, 2013 at 3:49 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sat, Apr 27, 2013 at 2:21 PM, Dean Landolt d...@deanlandolt.com
wrote:
On Fri, Apr 26, 2013 at 11:18 AM, Andreas Rossberg rossb...@google.com
wrote:
On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com
On Sat, Apr 27, 2013 at 5:46 PM, Mark Miller erig...@gmail.com wrote:
I am worried that we're again separated by a common terminology more than
we are by an actual technical disagreement. I am arguing against an
unconditional lift operation that would make a promise-for-promise. Or at
least
On Sun, Apr 28, 2013 at 1:46 AM, Mark Miller erig...@gmail.com wrote:
I am worried that we're again separated by a common terminology more than we
are by an actual technical disagreement. I am arguing against an
unconditional lift operation that would make a promise-for-promise. Or at
least
On Sun, Apr 28, 2013 at 3:41 AM, David Sheets kosmo...@gmail.com wrote:
On Sun, Apr 28, 2013 at 1:46 AM, Mark Miller erig...@gmail.com wrote:
I am worried that we're again separated by a common terminology more than we
are by an actual technical disagreement. I am arguing against an
On Sat, Apr 27, 2013 at 5:46 PM, Mark Miller erig...@gmail.com wrote:
I am worried that we're again separated by a common terminology more than we
are by an actual technical disagreement. I am arguing against an
unconditional lift operation that would make a promise-for-promise. Or at
least
Something that wasn't clear to me personally until reading the last few
posts: I suspect that some of the negative reaction to unwrapping/wrapping,
and the suggestion that FutureFutureT is a meaningful construct, comes
from the mindset of static typing - not in the sense that static types
Le 26/04/2013 00:21, Claus Reinke a écrit :
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted
A Future for a Future seems like a corner case compared to the
broader simplicity of an implicit unwrap.
The argument is not about whether FutureFuture... is a common
case. The Argument is that Future... and Array... and Optional...
and things that may raise catchable errors and other types
Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble trib...@e-dean.com wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs
On 26 April 2013 10:54, David Bruant bruan...@gmail.com wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helping users? authors (more than what I described at [2] which is derived
from my own
[adding public-script-coord and Anne]
Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
On 26 April 2013 10:54, David Bruant bruan...@gmail.com wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some people
(including me) like to call
Le 26/04/2013 13:24, Andreas Rossberg a écrit :
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows one
to create a promise whose eventual value is itself a
Let me take a crack at describing E's support for promises.
E has two modes for sending a message to an object. There is the
immediate send and the eventual send. If the Object is an
unresolved promise the immediate send will trap. (A promise can
be forced to resolve using the when
Yes, you do.
On Apr 26, 2013 2:54 PM, Kevin Smith zenpars...@gmail.com wrote:
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or
On Fri, Apr 26, 2013 at 9:28 AM, Alex Russell slightly...@google.comwrote:
Yes, you do.
Mark or Domenic, is the point about Q true as well? (That it could, in
principle, provide something like Future.accept, but it chooses not to.)
Just wanted to check before I say somethin' foolish : )
{
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows
one to create a
On 26 April 2013 14:29, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 13:24, Andreas Rossberg a écrit :
I'm not sure if your description of E is accurate -- I'd find that
surprising. It _is_ a perfectly sensible design to have transparent
futures that you can just use in place of the
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
Promise/A+ does not prohibit promises for promises. But in practice the
problem is
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted nesting
Perhaps you didn't read my post then?
Can you point to any code in wide use that makes use of this
thenables = monads idea you seem to be implicitly assuming?
Perhaps some of this generic thenable library code? I have never
seen such code, whereas the use of thenable to mean object with
a then method, which we will try to treat as
Bruant
Cc: Mark S. Miller; es-discuss
Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures)
Can you point to any code in wide use that makes use of this
thenables = monads idea you seem to be implicitly assuming?
Perhaps some of this generic thenable library code? I have
Le 26/04/2013 15:47, Claus Reinke a écrit :
My own argument is not for nested futures themselves, but (1) for
futures to offer the same interface (.of, .then) as other thenables,
which
(2) implies that there is to be no implicit lifting or flattening in
.then.
For promises, I don't expect to
From: David Bruant [bruan...@gmail.com]
Thoughts?
Since this entire problem seems predicated on Claus's misunderstanding of the
term thenable, which apparently has no basis in real libraries but instead
entirely in wishful thinking, it might be more prudent for him to use the term
monad
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I believe the controversy is over the number of resolution iterations
for a given wrapped value.
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big
On Fri, Apr 26, 2013 at 3:20 PM, David Sheets kosmo...@gmail.com wrote:
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I believe the controversy is over the number of resolution iterations
for a given wrapped value.
I think we all agree with the semantics
On Fri, Apr 26, 2013 at 9:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then
From: David Sheets [kosmo...@gmail.com]
From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
`FutureResolver`.
This is not correct. See Let resolve be a future callback for the context
object and its resolve
Promise/A+ does not prohibit promises for promises. But in practice the
problem is recognizing what is a promise.
I would say rather that we have two orthogonal, but
highly interfering issues:
1. Do we allow promises-(for-promises)+?
2. How do we recognize a promise type within the resolve
On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Sheets [kosmo...@gmail.com]
From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
`FutureResolver`.
This is not
From: David Sheets [kosmo...@gmail.com]
Why is there a semantic distinction between my thenables and your thenables?
Because your thenables are not to be trusted! They could do pathological things
like jQuery, or conceptually incoherent things like thenables-for-thenables.
Sanitation at the
On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote:
The fundamental controversy, as Juan just noted, is how to precisely
identify a promise in order to do either of these two things. This problem
isn't quite so clean cut, but it's much more important to solve. I've been
trying to
On Fri, Apr 26, 2013 at 4:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Sheets [kosmo...@gmail.com]
Why is there a semantic distinction between my thenables and your thenables?
Because your thenables are not to be trusted! They could do pathological
things like
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
Let me note that this is not the fundamental controversy (not for me,
anyway). The fundamental controversy is whether there should be any
irregularity at all, as is unavoidably introduced by implicit
Hi Bill,
I think I know what you mean by these terms, and what I think you mean is
correct ;). But given the history of promises and futures, you make two
unfortunate and confusing terminology choices: forced and wait.
Instead, E promises, like all JS promises, are inherently non-blocking. The
On Fri, Apr 26, 2013 at 8:45 AM, David Sheets kosmo...@gmail.com wrote:
Could you point me to some code that needs dynamic flattening?
From
https://github.com/promises-aplus/promises-spec/issues/101#issuecomment-16657518
```js
var promise = getDataFromServerUsingQ().then(function (data) {
Le 26/04/2013 17:25, Tab Atkins Jr. a écrit :
On Fri, Apr 26, 2013 at 3:19 AM, David Bruant bruan...@gmail.com wrote:
Your abstract example was:
If FutureFuturex can exist, then you'll have to write this
boilerplate code in a lot of places:
f.then(function res(v){
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and libraries
switch to using those (or a subclass of them) rather than rolling bespoke
promises.
Last I heard, jQuery has committed to never switching their promises
implementation to
On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and libraries
switch to using those (or a subclass of them) rather than rolling bespoke
promises.
Le 26/04/2013 17:58, Mark Miller a écrit :
However, the need for assimilation is history dependent. If there is
another plausible-enough path to adoption and widespread use of
promises that does not require assimilation, I would be very happy.
But I have not found any of the alternatives
On Fri, Apr 26, 2013 at 8:58 AM, Mark Miller erig...@gmail.com wrote:
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
Let me note that this is not the fundamental controversy (not for me,
anyway). The fundamental controversy is whether there should be any
On Apr 26, 2013 1:03 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and
libraries switch to using those (or a subclass of them) rather than rolling
bespoke promises.
Last I
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound that hard (library authors can jump in to say
2013/4/26 Mark Miller erig...@gmail.com
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
the term future
What are the chances of the WHATWG renaming the spec to DOMPromise?
Juan
___
es-discuss mailing list
On Fri, Apr 26, 2013 at 12:17 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
2013/4/26 Mark Miller erig...@gmail.com
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
the term future
What are the chances of the WHATWG renaming the spec to DOMPromise?
Le 26/04/2013 20:39, Domenic Denicola a écrit :
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound
Le 26/04/2013 20:36, Rick Waldron a écrit :
The libraries discussed in this and similar threads have the benefit
of very limited adoption, where breaking changes incur minimal costs.
jQuery doesn't have that luxury ;) [0] and therefore won't break
backward compatibility. I can assure you that
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be
compatible with Promise/A+ and not jQuery promises? Because more libraries
use Promise/A+? what about market share?
What we're discussing is not *compatibility* but *ability to
On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be
compatible with Promise/A+ and not jQuery promises? Because more
libraries use Promise/A+?
Le 26/04/2013 21:47, Domenic Denicola a écrit :
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be compatible with
Promise/A+ and not jQuery promises? Because more libraries use Promise/A+?
what about market share?
I realize I was
On Fri, Apr 26, 2013 at 6:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then
On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
[snip]
No. Future callbacks can return Futures, which then chain (the return
value of then adopts the state of the callback's return value). This
is the big monad benefit that we keep talking about.
[snip]
Shorter
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to actually
provide an example of where flattening is useful, that isn't (a)
assimilation, (b) a result of weird language semantics from some non-JS
language, or (c) an authoring
On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to actually
provide an example of where flattening is useful, that isn't (a)
assimilation, (b) a
On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 26, 2013 at 6:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Thanks for making these issues clearer to me Mark. I am
beginning to get some idea of the problems that JS promises face
given that they must have an object-like appearance.
I like the fact that in E, promises just work and I think of
Joule as a language where every value is a promise and
I think we see a correlation -- not a 1.0 correlation, but something. Those
who've actually used promise libraries with this flattening property find
it pleasant. Those who come from either a statically typed or monadic
perspective, or have had no experience with flattening promises, generally
I think flattening is also tied inextricably to the fact that promises are
a featureless wrapper for values. Nobody cares about promises-as-values
because of this featureless-ness. And because they are completely
uninteresting as values, programmers can think straight through to the
eventual
That's a good point. Neither the E language nor the Q library allow
subclassing of promises. The motivating reason in both cases is the
security properties that promises must provide. But you're right -- this is
an additional benefit. Promises/A+, being a minimalistic codification of
broader
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted nesting
There is little to be said about 1,
Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures)
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries
.
--
From: Claus Reinke claus.rei...@talk21.com
Sent: 4/25/2013 18:21
To: Mark Miller erig...@gmail.com; David Bruant bruan...@gmail.com
Cc: Mark S. Miller erig...@google.com; es-discusses-discuss@mozilla.org
Subject: Re: A Challenge Problem for Promise Designers (was: Re: Futures)
I'm still
On Thu, Apr 25, 2013 at 4:30 PM, Dean Tribble trib...@e-dean.com wrote:
I've built multiple large systems using promises. A fundamental distinction
that must be clear to the client of a function is whether the function goes
async: does it return a result that can be used synchronously or will
Hmm. I agree that the example code isn't relevant to JavaScript. For
background, the last time issues this came up for me was in the context of
a language keyword (which had other interesting but unrelated trade offs),
where it really did impose that interaction (call sites had to declare that
the
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble trib...@e-dean.com wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs that use promises internally (e.g., the
On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller erig...@gmail.com wrote:
The refactoring of putting the Q(srcP).then in the deposit method
unburdened all clients such as the buy method above from doing this
postponement themselves. The new buy method on page 13 now reads:
buy: (desc,
What is the semantics of Future.resolve?
On Thu, Apr 25, 2013 at 6:45 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller erig...@gmail.com wrote:
The refactoring of putting the Q(srcP).then in the deposit method
unburdened all clients such as the
On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller erig...@google.com wrote:
What is the semantics of Future.resolve?
Creates an already-accepted future using the resolve algorithm,
which is the same magic that happens to the return value of a .then()
callback (if it's a future, it adopts the
So how does the semantics of Q(x) differ from the semantics of
Future.resolve(x) ?
On Thu, Apr 25, 2013 at 8:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller erig...@google.com
wrote:
What is the semantics of Future.resolve?
Creates an
I’m not sure I fully grok the use cases for FutureResolver#accept and having
FutureFuturevalue. Having to call an Unwrap extension method on a
TaskTaskT in .NET is an unfortunate necessity. Also, since Future#then
implicitly resolves a future it is difficult to return a FutureFuturevalue
from
On Thu, Apr 25, 2013 at 8:52 PM, Mark S. Miller erig...@google.com wrote:
So how does the semantics of Q(x) differ from the semantics of
Future.resolve(x) ?
I suppose you tell me?
You offered, as an example of why recursive unwrapping was useful,
some example code that used Q(val).then(). The
95 matches
Mail list logo
