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
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
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
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 : )
{
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
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 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: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) {
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.
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 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 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
46 matches
Mail list logo
