- From: Mark Miller <erights@gmail.com>
- Date: Fri, 26 Apr 2013 08:58:47 -0700
- 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>
- Message-ID: <CAK5yZYgEDZZvhu9bORGBAO5oyCHV56ReRH3+dk33QGcqEK+Oeg@mail.gmail.com>
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg <rossberg@google.com> wrote: [...] > 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" mentality. 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.) -- Cheers, --MarkM
Received on Friday, 26 April 2013 15:59:14 UTC