Promises (was: Re: Light-weight monitor implementation?)

Colin Putney cputney at wiresong.ca
Thu Nov 3 13:19:56 UTC 2005


On Nov 3, 2005, at 7:41 AM, Cees De Groot wrote:

> http://www.erights.org/elib/distrib/pipeline.html and other pages  
> on that site.
>
> One of the biggest differences is that you can perform computations
> with promises - the result is another promise, etcetera. Only when you
> really really really need to do something acute to the promise you end
> up with, you block waiting for all the work to finish.
>
> So:
>
> foo := [1 + 2] asPromise.
> bar := foo + 3
> "bar is now a promise if foo wasn't finished yet, so doesn't block"
> Transcript show: bar printString; cr.
> "now we need to value of the whole thing, so that blocks"
>
> At least, that's what I seem to remember. Disclaimer: I'm getting
> seriously old so more and more memory cells are failing...

You also need to be able to handle broken promises. What if that  
block never does produce an answer? So something more like:


foo := [1 + 2] asPromise.

"this doesn't block, but bar is a promise as well."
bar := foo + 3

"this does block, but not indefinitely."
bar
	resolveIn: [:answer | Transcript show: answer printString; cr]
	onTimeout: [Transcript show: 'promise timed out'; cr].



E makes a syntactic distinction between immediate sends and eventual  
sends, so that if you try to make an immediate send to a promise  
you'll get an error. Bert, how does the Croquet version handle this?  
Do you just keep getting promises until you explicitly wait for  
resolution?

Colin



More information about the Squeak-dev mailing list