- From: Andreas Rossberg <rossberg@google.com>
- Date: Tue, 21 May 2013 11:39:25 +0200
- To: Tom Van Cutsem <tomvc.be@gmail.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>
On 20 May 2013 14:15, Tom Van Cutsem <tomvc.be@gmail.com> wrote:
> 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
> }
What's your definition of "entirely transparent" then? Or in other
words, what if I use 'promise' outside a when?
/Andreas
Received on Tuesday, 21 May 2013 09:40:15 UTC