Igor Stasenko wrote:
> Let suppose that Mr.Satan will rewrite an example above as following:
> 
> object eventual ifTrue: [100 atRandom seconds asDelay wait.  ^3].
> 100 atRandom seconds asDelay wait.
> ^4
> 
> When, in real case, a random delay could be replaced by any code which
> needs a time to evaluate.
> What is the answer then? :)

Same answer (though strictly speaking you may get an error that you 
can't *wait* in an eventual system). The reason being that <object> will 
only get an eventual ref to the block so it will only be able to send 
other eventual messages to it. Put differently, ifTrue: would need to be 
implemented as:

True>>ifTrue: aBlock
   "I am true, so evaluate aBlock"
   aBlock isBlock "if it's an immediate block..."
     ifTrue:[aBlock value] "... evaluate it directly ..."
     ifFalse:[aBlock eventual value] "... otherwise eventual"

(I'm ignoring the issues of meta-circularity for ifTrue: here; the above 
is purely conceptual) The main point is that because the evaluation of 
the block would be eventual it would *necessarily* evaluate after the 
immediate delay and the entire message has completed *regardless* of how 
long or how short that delay is. If that were different it would violate 
one of the fundamental axioms of event-loop concurrency (the fact that 
only one message is ever executed at the time) and wouldn't count as 
message passing concurrency anymore.

Cheers,
   - Andreas