Promises

Mark S. Miller erights at google.com
Wed Nov 14 12:11:00 PST 2012


On Wed, Nov 14, 2012 at 11:37 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> 2012/11/14 Andreas Rossberg <rossberg at google.com>
>
>> On 14 November 2012 18:41, Mark S. Miller <erights at google.com> wrote:
>> > Either way, Scala's
>> > unfortunate choice clearly violates this history in a confusing manner,
>> so
>> > I'd classify it as #4. Let's not repeat Scala's mistake.
>>
>> Just to reiterate, it's not just Scala, but more importantly also C++,
>> Java (to some extent), and several less mainstream languages. That is,
>> this use of terminology has quite a bit of history of its own, dating
>> back almost as far as E (and having developed more or less
>> independently).
>
>
> I still think futures connote strongly with blocking synchronization. If
> we'd add a concept named "future" to JS on the grounds that the same
> concept exists in Java and C++, developers will reasonably expect a
> blocking future.get() method.
>
> In my experience, the term "promise" is much more associated with
> non-blocking synchronization through .then or .when callback chaining
> (although ironically the name derives from Argus, which featured blocking
> promises. Argh! :-)
>

OTOH, the Argus promises were where promise pipelining <
http://en.wikipedia.org/wiki/Futures_and_promises#Promise_pipelining> was
invented, and this is a key feature of our distributed promises via
.send/.post. In this way, the Argus promises are the closest to ours.




>
> Cheers,
> Tom
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121114/9bab2029/attachment.html>


More information about the es-discuss mailing list