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

On Fri, Apr 26, 2013 at 8:58 AM, Mark Miller <erights@gmail.com> wrote:
> 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.
>
> 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.

Are you referring to this example, from your OP in the earlier
"Challenge for Promise Designers" thread?

>    deposit: (amount, srcP) =>
>      Q(srcP).then(src => {
>        Nat(balance + amount);
>        m.get(src)(Nat(amount));
>        balance += amount;
>      })

If so, then the effect of this code is to allow srcP to be *either* a
plain value or a promise for a value, and the deposit() function
should work equally well with either.  (As opposed to always expecting
a plain value, which requires the call sites to wait on the resolution
of their promises, or always expecting a promise, which requires the
call sites to wrap their plain values.)

This can be trivially rewritten to the same effect with Futures:

    deposit: (amount, srcP) =>
      Future.resolve(srcP).then(src => {
        Nat(balance + amount);
        m.get(src)(Nat(amount));
        balance += amount;
      })

Future.resolve() is the future-coercion operator: if you pass it a
future, it returns a new (but equivalent) future; if you pass it a
non-future, it returns a future for that value.  Using it allows you
to write functions that can take either plain values or futures for
values.

> 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.

I agree that assimilation might be required to be recursive, to be
maximally useful.  I've got no problem with that - assimilation is an
interface with the outside world, is often magical in these kinds of
situations, and is a separate function from what "normal" promises
will use.

I have not yet seen any arguments *for* flattening that aren't about
assimilation, weird language constructs that aren't applicable to JS,
or authoring errors.  My response to David Bruant in
<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0239.html>
covers this objection in slightly more detail.

If you believe that flattening really is necessary, or even beautiful,
I don't think you've demonstrated it yet (or if you have, I've
misunderstood your examples, and would appreciate correction).

> 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.

Actually, I keep using the term Future because that's the current name
for the standardized version of promises, and it provides an easy way
to distinguish between default flattening and not - "promise" refers
to Promises/A+, which has default flattening, while "future" refers to
DOM Futures, which flattens monadically.

Anyone who reads territoriality into this is reading too much.  Don't
worry about it.  These things will get defined somewhere, under some
name, and we'll decide that all later.

> 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.)

As far as I can tell, your example does not show any flattening at
all.  I responded as such in your earlier thread, and asked you to
correct me if I was making wrong assumptions at any point, but you
appeared to have jumped threads (I don't blame you - the other one
exploded over night/this morning).  So, I'll pose the question to you
again: am I wrong, or does your example have nothing to do with
flattening?

~TJ

Received on Friday, 26 April 2013 18:27:57 UTC