Sean, Tara and I are working on a concurrent programming language. It's based on message passing. Message passing, you say sarcastically, that's a new idea: look at Smalltalk and its object oriented progeny like Java.

But our messages are different! They're asynchronous. Instead of sending a message and waiting for the response, you continue on your merry way.

You may have had this idea before. I did -- it's not really a difficult concept. The question is, when you need to get a value back from that message that you sent (like a return value), how do you do it? Stop and think about this. How do you do it?

One idea is to send a return port along with the message, and have the client send you data along that port. This is okay, and our language certainly supports it. But what if the port needs a bunch of different pieces of data as results from a bunch of different messages? You have a serious data collection problem, where all your return ports are invoked at different, unpredictable times.

Okay, so instead, let's try this -- when you send, you get back a token (let's call it a Future) which you can "force" in order to retrieve the value. When you force a future, your message blocks until the desired message produces a value, and then you get it. But let's add another constraint: messages should never block. (I'll get to why this is useful in another post.)

So what, then? Here's our proposal: sending Futures as arguments to a message causes them to be resolved before that message is delivered. That's kinda weird... but it solves our blocking problem -- the only "blocking" that occurs is that a message's delivery might be delayed, but since they are asynchronous, it doesn't matter. It also makes it easy to do the data-collection problem, as you can start a bunch of asynchronous messages and then pass all their futures to the same place -- the place where you do your work depending on those values.