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

What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

From: Mark Miller <erights@gmail.com>
Date: Fri, 26 Apr 2013 08:58:47 -0700
Message-ID: <CAK5yZYgEDZZvhu9bORGBAO5oyCHV56ReRH3+dk33QGcqEK+Oeg@mail.gmail.com>
To: Andreas Rossberg <rossberg@google.com>
Cc: Dean Landolt <dean@deanlandolt.com>, David Bruant <bruant.d@gmail.com>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg <rossberg@google.com>

> 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
> flattening. The problem you describe just makes the negative effect of
> that irregularity worse.
> /Andreas

First, my apologies to all for replying after having only skimmed this
morning's messages. My sense is that indeed there are several different
arguments going on simultaneously that are often difficult to untangle.

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
terms of the uniform non-flattening semantics you desire.

Second, I intend it to show why default flattening is desirable. By itself
the challenge problem does not argue for or against
1) the possibility of promises-for-promises, as Alex correctly observes, so
long as this is clearly marked as "only for experts"
2) the unwrapping of thenables
3) assimilation -- the recursive unwrapping of thenables.
4) whether promises recognize their own bretheren as promises, or just
treat them all as thenables
5) whether some continue to alienate the JS promise community by continued
use of the term "future"
6) what kind of extension mechanism (e.g., subclassing or makeRemote) a
promise system should provide
7) under what organization should promises be standardized

So that we can refer to it in the same namespace, let's call the
controversy about default flattening #0

Obviously, the answer to #4 determines whether there is a meaningful
difference between flattening and assimilation.

These are each important distinctions. My position is that default
flattening is a must. That the beauty of flattening is an important
principle, but assimilation is an expedient but necessary hack. The need
for flattening is eternal, as the joy of flattening has survived through
several languages and the pain of non-flattening has been shared experience
across many languages. 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 posted so far to
be plausible enough.

Regarding #5 and #7, can we put these to bed already? AFAICT, the clear
consensus of these lists is that TC39 will be proceeding with promises. The
continued occasional use of "future" terminology seems to be only
territory-marking behavior, and divides the community with an "us vs them"

I agree with Alex that the main *technical* disagreement with DOMFutures is
#1. My example shows the utility and beauty of flattening. Could you, or
anyone who argues for a "fulfill" (aka "accept") operation, show an example
of the utility of non-flattened promises? (And please keep this question
distinct from questions about thenables.)

Received on Friday, 26 April 2013 15:59:14 UTC

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