On 2009-12-18, at 8:29 AM, Andreas Raab wrote:
Colin Putney wrote:
BTW, what's the larger plan here? Do you want to introduce Islands as well? Bring Squeak and Croquet closer together so that (eventually) Croquet can be based on a Squeak base image? I do see a lot of value in this stuff, and I think it would be a great way to formalize the implicit event loop that we have with Morphic. On the other hand, this is the tip of a very large iceberg, and navigating might be easier if we had a destination in mind.
Bringing Squeak and Croquet closer together is one of the less important goals for me personally. But future messaging is valuable outside of Croquet; and the real goal for me is to improve the support for concurrency and distributed computation in general (think Erlang). Lock-free communication is a really interesting starting point because it enables many other things. Croquet is a natural part of this but it's not the end goal.
Ok, good to hear. Interest in alternative models of concurrency has been gaining steam in the community for the last year or so, but this is the first time it's appeared in the trunk. I think we should collectively think and talk about where we want to end up with this stuff. It's got enormous potential, but if we're not careful we could end up with a mishmash of paradigms, and leave things less stable and more difficult to understand than we have today.
On 2009-12-18, at 9:13 AM, Andreas Raab wrote:
Colin Putney wrote:
On 2009-12-18, at 1:01 AM, Josh Gargus wrote:
Pretty interesting. I'm a bit ambivalent about a magic compiler change like this, but you make a pretty strong case for it's usefulness.
That's why Andreas asked me to add the FutureMaker class and the Object future/future: implementations. The same semantics are implemented without any compiler magic; the addition of FutureNode to the compiler is then merely an optimization.
In that case I'd say let's hold off on the compiler changes, until we find that we're using #future so much that it should be inlined.
Oops, sorry forgot to comment on this one. Although strictly speaking the inlining is optional, it is very, very desirable because one of the things the compiler does is omitting the need to generate return promises for every single future message being sent. Since the compiler knows whether the result of a message is being used or not, we can avoid creating promises for messages where the result isn't used. In practice, this turns out to be a significant improvement; for example in Teleplace the ratio is 4:1 for futures without result promises compared to those with (886:196 to be precise; this also gives you a feel for how much we use future messages - they are used more often than #collect: which has 976 senders in the same image). I'd like to retain that optimization if at all possible.
Ok, sounds good.
Colin