Erlang hints from an CO junkie

[James Hague]

>  I think you may be missing the point (or perhaps I am). It matters 
> not how the critter is displayed  or  the  fact that  it is  moved
> once per frame. What matters is that in real  life the critter would
> be concurrent, so it makes allot of sense to model the critter as a
> concurrent process in the system.

I disagree.  Or at least I'll say "it depends."  All you really need in this
case is a function that you call with the old critter state and you get back
a new critter state.  That function could simply take a record, which
includes either a state variable or fun, and returns a new record.  Or it
could send an update message to a process and wait for the result.  It
doesn't matter.  There's no true concurrency here.