W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: Future cancellation

From: Bill Frantz <frantz@pwpconsult.com>
Date: Wed, 1 May 2013 11:04:01 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
cc: Brendan Eich <brendan@mozilla.com>, public-script-coord@w3.org, es-discuss <es-discuss@mozilla.org>
Message-ID: <r422Ps-1075i-911E04315EDF4FAFBA09E4353F68A52E@Williams-MacBook-Pro.local>
On 5/1/13 at 7:54 AM, jackalmage@gmail.com (Tab Atkins Jr.) wrote:

>On Wed, May 1, 2013 at 5:50 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>On 4/30/13 at 11:04 PM, jackalmage@gmail.com (Tab Atkins Jr.) wrote:
>...
>
>>> 1. Some promises are holding onto resources (locks, network
>>> connections, cpu time) which will be disposed of when they're
>>> finished.
>>
>>I think this statement is wrong. Promises don't hold resources. They are a
>>placeholder for a value to be provided later. Perhaps the computation which
>>may provide the value at some future time holds a resource, or the
>>computation which will consume the value when it is resolved holds a
>>resource (generally a poor programming practice), but the promise itself
>>doesn't hold resources.
>
>Semantics.  ^_^  The promise can represent a computation, which can
>hold some releasable resources.

To my mind this is an important distinction. The promise does 
not represent the computation. It represents the result.

Any representation of the computation itself bring in a whole 
lot baggage which includes, the problem of managing distributed 
computation in the cloud plus a lot of other issues. Dragging 
this stuff into the base level of a programming language is a 
bad crossing of abstraction levels.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 
Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, 
CA 95032
Received on Wednesday, 1 May 2013 18:04:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC