Promises

Andreas Raab andreas.raab at gmx.de
Fri Nov 4 03:52:31 UTC 2005


Bert Freudenberg wrote:
> Croquet of course distinguishes between immediate and eventual sends.  
> However, in the current implementation (which is not yet complete)  
> there is not yet much magic to make the code look like above. For  
> example, a promise does not yet resolve magically to its value. You  
> have to manually retrieve the result:
> 
>     foo := 1 futureSend: #+ with: 1.
>     foo whenComplete: [
>         bar := foo result futureSend: #+ with: 3.
>         bar whenComplete: [
>             answer := bar result.
>             Transcript show: answer printString; cr]]

Actually, the latest implementation does support the "future" keyword 
which makes the above look more like:

     (1 future + 1) whenComplete:[:foo|
       (foo future + 3) whenComplete:[:result|
         Transcript show: result printString]].

Oh, and I think this example is extremely badly chosen. A better one 
would be something like:

     "Create a new TSpace"
     (island future new: TSpace) whenComplete:[:space|
       "Create a new TFrame"
       (island future new: TFrame) whenComplete:[:frame|
         "Add TFrame to TSpace"
         space future addChild: frame.
       ].
     ].

With promise pipelining (which avoids the network roundtrip time 
inherent in any of the completions above), this just becomes:

    "Create a new TSpace"
    space := island future new: TSpace.
    "Create a new TFrame"
    frame := island future new: TFrame.
    "Add TFrame to TSpace"
    space future addChild: frame.

> Of course, once this is fully working and debugged, a bit of compiler  
> magic could allow you to write this as:
> 
>     foo := 1 ?+ 1.
>     bar := foo ?+ 3.
>     answer := bar resolve.
>     Transcript show: answer printString; cr
> 
> where "?+" would be an eventual send ... or any other syntax we might  
> come to like.

Eeek. It will be "future" to emphasize the time-based nature of 
computation. And binary symbols are evil anyway ;-)

> As for broken promises, these are not implemented, yet.

So is promise-pipelining (which I think is more important). But both are 
on my TODO list.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list