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
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...
More information about the es-discuss