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

Tom Van Cutsem tomvc.be at gmail.com
Mon May 20 05:15:59 PDT 2013

(catching up on old threads, sorry for the asynchrony [no puns intended

On 26 April 2013 12:19, David Bruant <bruant.d at 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 at 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.

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

More information about the es-discuss mailing list