A Challenge Problem for Promise Designers

Mark S. Miller erights at google.com
Sat Apr 27 10:05:30 PDT 2013

On Sat, Apr 27, 2013 at 9:55 AM, David Sheets <kosmo.zb at 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>
    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)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130427/4e29f804/attachment.html>

More information about the es-discuss mailing list