non-self referencial cyclical promises?
tribble at e-dean.com
Wed Feb 24 22:00:01 UTC 2016
I agree that the standard shoudl require a deterministic error, and I
thought it did. In
6. If SameValue(resolution, promise) is true, then
> a.Let selfResolutionError be a newly created TypeError object.
> b.Return RejectPromise(promise, selfResolutionError).
I suspect I assumed to much for "SameValue" here though. There's no
well-defined other semantic answer to a cycle; it essentially always
represents a bug, but could emerge dynamically out of bad code. You must
either catch that as soon as possible or it's extremely difficult to
Another approach to efficiently achieve this in the implementation is to
vigorously shorten targets. In this approach, the `bf(a)` would first
shorten `a` so that it's internally pointing at the cell that `bf` will
resolve to (chains are typically short, so keeping chains short is
typically fast). Then the cycle check is simple and O(1). All the work is
in shortening. There are some patterns that can make for interim long
chains but they are straightforward to avoid.
On Wed, Feb 24, 2016 at 12:16 PM, Mark S. Miller <erights at google.com> wrote:
> On Wed, Feb 24, 2016 at 11:54 AM, Bergi <a.d.bergi at web.de> wrote:
>> Bradley Meck wrote:
>>> I was doing some recursive data structure work and ended up with a
>>> promise that did not use a direct self reference. It can be reduced down
>>> var af, a = new Promise(f=>af=f);
>>> var bf, b = new Promise(f=>bf=f);
>>> af(b);bf(a); // the problem
>>> a.then(_=>_) // some env/libs need this to start checking status
>>> According to
>>> it looks like this should cause a recursive and infinite set of
>> I fear that's what the standard says, yes. The ES6 spec does too many
>> (and in some cases, unreasonably many) `then` calls on promises anyway to
>> be followed by an efficient promise implementation.
>> [Promises/A+](https://promisesaplus.com/) in contrast says
>> | Implementations are encouraged, but not required, to detect such
>> | recursion and reject promise with an informative TypeError as the
>> | reason.
> I think the standard *should* require a deterministic error. E <
> Q, and my own Q-like system <
> https://github.com/tvcutsem/es-lab/blob/master/src/ses/makeQ.js#L700> all
> do. Within an engine, this technique should be straightforward to implement
> without slowing down the non-cyclic case.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss