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

Andreas Rossberg rossberg at google.com
Tue May 21 02:39:25 PDT 2013


On 20 May 2013 14:15, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 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
> promise:
>
> when ( promise ) -> {
>   // code here executed in later turn, when promise is fulfilled
>   // within this block of code, the promise *is* its fulfilled value
> }

What's your definition of "entirely transparent" then? Or in other
words, what if I use 'promise' outside a when?

/Andreas


More information about the es-discuss mailing list