2013/5/21 Andreas Rossberg
> 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, E has two mes
On 20 May 2013 14:15, Tom Van Cutsem wrote:
> 2013/4/26 Andreas Rossberg
>>
>> 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 value they eventually
>> get re
(catching up on old threads, sorry for the asynchrony [no puns intended
;-)])
On 26 April 2013 12:19, David Bruant 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
> > this promis
On Apr 26, 2013 1:03 PM, "Domenic Denicola"
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 heard, jQuery has commit
On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola
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 heard, jQuery
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 8:45 AM, David Sheets 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) {
>>
On Fri, Apr 26, 2013 at 4:03 PM, Domenic Denicola
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 jQuery, or conceptually i
On Fri, Apr 26, 2013 at 3:19 AM, David Bruant wrote:
> Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
>> On 26 April 2013 10:54, David Bruant wrote:
>>> The Priority of Constituencies [1] asks us to be remain careful about
>>> theoretical standpoints. How does the theoretical par
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 b
On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola
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 correct. See "Let
>
>
> 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 "res
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 resol
On Fri, Apr 26, 2013 at 3:20 PM, David Sheets wrote:
>> 2013/4/26 Kevin Smith
>>>
>>> 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 i
> 2013/4/26 Kevin Smith
>>
>> 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 problem!)
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"
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 u
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 t
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 tre
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?
2013/4/26 Kevin Smith
> 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 recognizing what i
On Fri, Apr 26, 2013 at 9:28 AM, Alex Russell wrote:
> 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 : )
{ Kevin }
___
Yes, you do.
On Apr 26, 2013 2:54 PM, "Kevin Smith" 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 not the API
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 promis
On 26 April 2013 12:19, David Bruant 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 "compositionality".
>>
[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 wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helpin
On 26 April 2013 10:54, David Bruant 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 experience)? imple
Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble 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 i
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 Future> is a common
case. The Argument is that Future<...> and Array<...> and Optional<...>
and things that may raise catchable errors and other types have
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
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 Future> is a meaningful construct, comes
from the mindset of static typing - not in the sense that static types
themselves are
On Thu, Apr 25, 2013 at 8:52 PM, Mark S. Miller 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 surrounding
expl
I’m not sure I fully grok the use cases for FutureResolver#accept and having
Future>. Having to call an Unwrap extension method on a
Task> in .NET is an unfortunate necessity. Also, since Future#then
implicitly resolves a future it is difficult to return a Future>
from a then.
In every case w
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. wrote:
> On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller
> wrote:
> > What is the semantics of Future.resolve?
>
> Creates an already-accepted future using the "res
On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller 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 state; otherwise, it
What is the semantics of Future.resolve?
On Thu, Apr 25, 2013 at 6:45 PM, Tab Atkins Jr. wrote:
> On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller 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
On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller 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, paymentP) => {
>
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble 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 implementation of ma
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 4:30 PM, Dean Tribble 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 the
> result o
minority libraries who have misinterpreted
> what it means to be a thenable.
> --------------
> From: Claus Reinke
> Sent: 4/25/2013 18:21
> To: Mark Miller ; David Bruant
> Cc: Mark S. Miller ; es-discuss
> Subject: Re: A Challenge Problem for Promise Designe
>
Cc: Mark S. Miller<mailto:erig...@google.com>;
es-discuss<mailto:es-discuss@mozilla.org>
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
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,
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 agreem
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 va
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
thi
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
thin
47 matches
Mail list logo
