Lambda the Ultimate

Basically, to access or set the variable you send a message. The listening process takes appropriate action, calls itself with a new state, and listens again. Since it's tail recursive, the stack doesn't blow up.

I think the .pdf of the erlang book shows how to maintain a state machine with this method.

I have been doing lots of thinking and experimentation with how Erlang could be used to write games, and I think your comment above oversimplifies things. Sure, you can encapsulate data with tail recursive calls, but that's only the beginning.

Moving every game object into its own process is not necessarily the right way to go--for Erlang. It is a great way to write a state machine, but all object positions and animation states (etc.) need to be accessible somewhere. You could have a bunch of objects and processes reporting to a database process that tracks everything, but it's not clear if this is a real concurrency win. (Remember, in a game everything operates in lock-step fashion based on internal ticks of the clock.) Each object process also needs to respond to various messages from outside stimuli, and it's not clear how to nicely write a state machine that can also respond to these events.

Additionally, I've found that being functionally pure within a single process isn't as much of a win as I once thought it would be. For simulation-style programs, it can lead to contrived code. Many a time I've wished for both updateable local and process-global variables (and I've done quite a bit of functional programming, so this isn't coming from inexperience).

Should we take your enthusiasm for Erlang in parallel computing combined with your educational background as a damning indictment of the state of data-parallel Haskell? :-)

Laugh, not at all. I don't know much about Parallel Haskell, so I'm certainly not damning it in the least. From what little I know about Data Parallel Haskell, DPH is probably much more suitable for parallel applications where computations and maximising CPU power are important, such as scientific computations. A lot of the motivation for the recent work on Associated Types in Haskell came from the scientific application background. Erlang, on the other hand, is much more suitable for highly concurrent I/O-bound applications, where CPU isn't so important, such as network servers.

http://mirror.linux.org.au/pub/linux.conf.au/2007/video/friday/252.ogg

This was a really good talk. It's pretty exciting to think of Erlang being properly introduced to such a well-suited audience. André, you'll never pay for beer at an Erlang conference. :-)

I wouldn't say that it's usually important to request Erlang processes to shutdown like with the diediedie message. Terminating an Erlang process with exit is like terminating a Unix process with SIGTERM or SIGKILL. Erlang processes have separate heaps so they categorically don't have the problems of e.g. Java's Thread.stop() or Lisp's INTERRUPT-THREAD where a half-finished update can put a shared heap into a funny (or perhaps "hilarious") state.

The normal way to build an Erlang system is so that it neatly handles the termination of any process at any point of execution so that you're robust to your own bugs. Once you've done this it's not particularly scary to deliberately crash things, even in live telecom systems. It's like the comfort and predictability you have in kill'ing processes on a Unix system.

The crash-only software paper said this the best. I would imitate Dijkstra and summarise that "Graceful shutdown is just a special case of crashing, and not a particularly interesting one at that."

NOTE: I can't edit that inappropriate "I disagree" out of the subject so please just ignore it. :-)

...have fixed your subject line. The DIY solution is to delete the newline at end to see the hidden bits.

Thanks for the kind comments Andrae and Luke (and also to dnz -- I didn't even realise that the video was up yet). Not paying for beer at an Erlang conference may be a bad idea after a few hours, though!