W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

From: David Sheets <kosmo.zb@gmail.com>
Date: Fri, 26 Apr 2013 15:52:54 +0100
Message-ID: <CAAWM5TwjXwXKBs2N3_E9QO+JvAXK=F7G1_WdG6ibAdNGAUjJsg@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Juan Ignacio Dopazo <dopazo.juan@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> From: David Sheets [kosmo.zb@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 algorithm." inside the resolve algorithm itself. DOM Futures are recursive, just like Promises/A+.

Ah, you are correct and this would appear to unnecessarily break
expected identities. Though, it's at least consistent instead of
special casing its own promises.

>> Have I presented this correctly?
> Yes.
>> Why is it a problem to specify a single level of assimilation instead of sometimes-flattening "thenables" but never flattening promises?
> The idea is that conformant libraries may want to prohibit promises-for-thenables (since, as discussed many times already, they are nonsensical, unless you care more about monads than you do about promises---which all promise libraries I know of do not). To do so, two things must occur:
> 1. The library must never allow creation of promises-for-thenables. That is, it must not provide a `fulfilledPromise(value)` method, only a `resolvedPromise(value)` method. DOM Future violates this by providing `accept(value)`, but presumably TC39-sanctioned promises will not provide such a method..
> 2. The library must prevent thenables-for-thenables from turning into promises-for-thenables via assimilation. Instead, it must do recursive unwrapping.
> In this way, Promises/A+ allows promises-for-promises within a library, if that library allows creation of such things in the first place (like DOM Future does). But it does not allow promises-for-thenables, i.e. it does not allow foreign promises-for-promises to infect a library with multiple layers of wrapping. Multi-layered wrapping *must* stay within a single library..

Why is there a semantic distinction between my thenables and your thenables?

If someone is using nested thenables, presumably they have a good
reason. Promises/A+ acknowledges this possibility by allowing
own-promises to nest. If we are interesting in constructing the "most
standard" promises system, surely this system must grant other,
foreign systems the same possibility of nesting own-promises without
interference? Of course, these systems also control their own
resolution semantics and *could opt* to magically flatten all results.

Could you point me to some code that needs dynamic flattening?

I understand the need for automatic lifting and 1-level assimilation.
I use these a lot. I'm still fuzzy on the utility of flattening k
levels for dynamic k.


Received on Friday, 26 April 2013 14:53:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC