Igor Stasenko wrote:
>> but it is still deadlock-free since there is no wait involved (neither
>> "classic" nor "busy-wait). In fact, we use recursions like the above in
>> various places in Croquet.
> 
> See, unless you make all message sends in language as futures, you
> can't guarantee that  some code will not end up with locking
> semantics.

Not "all messages sends". Only messages between concurrent entities 
(islands). This is the main difference to the all-out actors model 
(where each object is its own unit of concurrency) and has the advantage 
that you can reuse all of todays single-threaded code.

> Lets see , what is happen if we have only a future sends.
> Then, given code:
> a print.
> b print.
> 
> will not guarantee that a will be printed before b.

Actually it will, if and only if a and b are in the same unit of 
concurrency (island). Your example is a bit misleading because of having 
different receivers - if those were in different islands then indeed 
there will be no guarantee that a prints before b. So for simplicity 
let's change this to:

   Transcript future print: a.
   Transcript future print: b.

Do we need a whenResolved: block to serialize execution? No we don't 
because messages between two islands are executed in the order in which 
they were scheduled. Everything else would be a straight ticket to 
insanity ;-)

> Yes, we can make 'futureA whenComplete:'  check implicitly (by
> modifying VM), then we can preserve old code. But do we really need a
> futures everywhere?

No, we don't. See above.

> Or we give up with an imperative style and use something different
> which fits better with futures, or we give up with futures.

The nice thing about futures is that they can be put on top of 
everything else. We use them in Croquet today.

> Or, we using both of them by mixing.. (which i think is most
> appropriate).. But then, stating that such system can be really
> lock-free, is wrong, because it depends on decision of concrete
> developer and his code.

This may be the outcome for an interim period. The good thing here is 
that you can *prove* that your program is deadlock-free simply by not 
using waits. And ain't that a nice property to have.

>>> As for GC - you have automatic memory management instead of manual.
>>> But there's no automatic algorithm management and never will be ,
>>> given any language :)
>> And what's that supposed to mean?
>>
> I pointed that futures as an 'automatic lock-free' approach is not
> quite parallel to 'automatic memory management by GC'.

The similarity is striking. Both in terms of tradeoffs (trade low-level 
control for better productivity) as well as the style of arguments made 
against it ;-) Not that I mind by the way, I find these discussions 
necessary.

Cheers,
   - Andreas