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

Re: A Challenge Problem for Promise Designers

From: Mark S. Miller <erights@google.com>
Date: Sat, 27 Apr 2013 10:05:30 -0700
Message-ID: <CABHxS9j8CKP7n9ogHJCQwG2KcFGxjYpgBu7-jUa=CFvJd62N3g@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: Ron Buckton <rbuckton@chronicles.org>, David Bruant <bruant.d@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Mark Miller <erights@gmail.com>, Dean Tribble <tribble@e-dean.com>
On Sat, Apr 27, 2013 at 9:55 AM, David Sheets <kosmo.zb@gmail.com> wrote:
[...]

> I think the major point of confusion in these discussions is the
> result of the framing of the discussion in terms of "flattening". I
> believe most beneficial viewpoint is that of "autolifting".
>
> That is, the exceptional case is not when the function argument of
> "then" returns a Future+ that gets "flattened" but rather when the
> function argument of "then" returns a non-Future that gets
> automatically lifted into a Future.
>
> This change in perspective is non-obvious because in many of these
> APIs there is no succinct lifting operation to make a Future from
> another value. This is a major reason why something like Future.of
> (Future.accept) is important.



I was following you until this last paragraph. As you define autolifting in
the first two paragraphs, Q(x) would be an autolifting operation. It has
the signature:

    promise<t> -> promise<t>
or
    t -> promise<t> // if t is not itself a promise type

Are you distinguishing "autolifting" vs "lifting"? If so, why do you think
it is important or desirable to provide a lifting operation (as opposed to
an autolifting operation)?


-- 
    Cheers,
    --MarkM
Received on Saturday, 27 April 2013 17:05:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC