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

(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
promise:

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.

Cheers,
Tom