Am 03.11.2005 um 14:19 schrieb Colin Putney:

>
> 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?

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]]

However, what does already work is that the receiver of a futureSend  
can live in different image on a different host :)

The execution semantics are such that these blocks are not just  
forked, but are scheduled to be executed non-preemptively (event-loop  
concurrency), it uses the same asynchronous scripts like Tweak does.

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.

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

- Bert -