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

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

From: Tom Van Cutsem <tomvc.be@gmail.com>
Date: Mon, 20 May 2013 14:15:59 +0200
Message-ID: <CAKDfNj9HtW4Xc-B4jokLvp8wjTc3KqDK6r1T8nnDpt7hzJ5bKQ@mail.gmail.com>
To: Andreas Rossberg <rossberg@google.com>
Cc: David Bruant <bruant.d@gmail.com>, "Mark S. Miller" <erights@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Mark Miller <erights@gmail.com>, Dean Tribble <tribble@e-dean.com>, es-discuss <es-discuss@mozilla.org>
(catching up on old threads, sorry for the asynchrony [no puns intended

On 26 April 2013 12:19, David Bruant <bruant.d@gmail.com> wrote:
>  > I have read somewhere (I can't remember where, hopefully MarkM will
> confirm
> > or say if I imagined it) that in E, if a variable contains a promise and
> > this promise is resolved, then the variable unwraps its value and
> > referencing to the variable suddenly means referencing to the value.
> > Promises are so deeply embedded in the language (syntax included) that
> this
> > unwrapping is seamless.

I can confirm that this is correct: E promises, once fulfilled, are
indistinguishable from their fulfilled value.

2013/4/26 Andreas Rossberg <rossberg@google.com>

> I'm not sure if your description of E is accurate -- I'd find that
> surprising. It _is_ a perfectly sensible design to have transparent
> futures that you can just use in place of the value they eventually
> get resolved to (let's call that value their 'content'). In fact, that
> is how futures/promises where originally proposed (back in the 70s)
> and implemented (e.g. in MultiLisp in 85, Oz in 95, and others later).
> However, there are really only two consistent points in the design
> space:
> 1. Either, futures are objects in their own right, with methods and
> everything. Then they should be fully compositional, and never be
> equated with their content, even after resolved (because that would
> change the meaning of a reference at locally unpredictable points in
> time).
> 2. Or, futures are entirely transparent, i.e. can be used everywhere
> as a placeholder for their content. In particular, that means that
> 'f.then' always denotes the 'then' method of the content, not of the
> future itself (even when the content value is not yet available).
> Unfortunately, option (2) requires that accessing a future that is not
> yet resolved has to (implicitly) block until it is (which is what
> happens in MultiLisp and friends). That only makes sense with threads,
> so I don't see how it can be reconciled with JavaScript.

Your conclusion is based on the premise that the operation used to
synchronize on the promise is expressed as a method.

E reconciles entirely transparent promises with non-blocking semantics by
introducing a language construct, called "when", to await the value of a

when ( promise ) -> {
  // code here executed in later turn, when promise is fulfilled
  // within this block of code, the promise *is* its fulfilled value

Semantically, the "when" operation acts on the promise itself, not on its
fulfilled value.
This distinction is blurred in JavaScript as "when" is expressed as a
".then" method on an explicit promise object.

Received on Monday, 20 May 2013 12:16:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC