Lots of concurrency

Lex Spoon lex at cc.gatech.edu
Thu Oct 18 03:18:28 UTC 2001


> Event handlers have lots in common with what I'm suggesting. Here are
> differences (though I admit I have yet to look at Morphic carefully and plan
> to):
> 
> 1. All communication is asynchronous. This would translate into never using
> call/return message sending but instead posting events and have event
> handlers.

Nice...

> 
> 2. Morphs are tied to graphics - I'm suggesting a general style of computing
> that includes graphics but also quick sort and bank accounts.

Cool!  And why not, after all?


> 
> 3. Every object is a "thread" as you suggest. I'm agnostic about whether the
> iteration is implicit, iterative as in your example, or tail recursive (as
> is the common programming technique in concurrent logic programming).

Treating threads as your objects sounds like a nice approach.  It
certainly makes parallelism a fundamental feature of the language!


> 
> 4. I'm a bit unclear about how you would express "When the ball gets close,
> do this".  Does each object periodically check its distance from the ball or
> can it register and be notified?

The nicest way would be literally, you write down something like:

	(ball distanceFrom: self) < 10  ===>    "...do this..."

This is extremely tough on the language implementation, though, so in
practice, you might just check very frequently, as you suggest:

	(true)  ===>
		(ball distanceFrom: self) < 10  ===>    "...do this..."


Either way, notice that there's this pattern of "when this happens, I
run this handler".  There is an infinite loop around the whole program,
but the programmer doesn't have to write it down.


Now here's where I get a little lost:


> I agree. Mixing concurrency and shared state causes headaches that we all
> want to avoid. My answer is that there is no shared state and no process
> state (there is no *position* in a computation to worry about - remember I'm
> getting rid of sequential composition). There are just concurrent objects
> that send messages asynchronously. E.g. actors. Though I'm arguing for
> something a bit more flexible than actors where there can be multiple mail
> boxes, where mail boxes are first class, etc.


I don't see how this can work in practice.  For a simple example, how
would you do BouncingAtomsMorph in your system?  In Squeak, each atom
currently has a position stored in an instance variable -- i.e., state. 
How do you get rid of the state in something like an atom bouncing
around?  Move it into the messages?

How does an atom decide when it is close to the edge of the screen and
needs to bounce into a different direction?  And for bonus, how do atoms
infect each other, i.e., how do you tell when two atoms of different
color are near each other?


-Lex




More information about the Squeak-dev mailing list