Modelling graphs with processes in Erlang by Nick Gibson.
From the post:
One of the advantages of Erlang’s concurrency model is that creating and running new processes is much cheaper. This opens up opportunities to write algorithms in new ways. In this article, I’ll show you how you can implement a graph searching algorithm by modeling the domain using process interaction.
I’ll assume you’re more or less comfortable with Erlang, if you’re not you might want to go back and read through Builder AU’s previous guides on the subject.
First we need to write a function for the nodes in the graph. When we spawn a process for each node it will need to run a function that sends and receives messages. Each node needs two things, its own name, and the links it has to other nodes. To store the links, we’ll use a dictionary which maps name to the node’s Pid. [I checked the links and they still work. Amazing for a five year old post.]
In the graph reading club discussion today, it was suggested that we need to look at data structures more closely. There are a number of typical and not so typical data structures for graphs and/or graph databases.
I am curious if it would be better to develop the requirements for data structures, separate and apart from thinking of them as graph or graph database storage?
For example, we don’t want information about “edges,” but rather data items composed of two (or more) addresses (of other data items) per data item. Or an ordered list of such data items. And the addresses of the data items in question have specific characteristics.
Trying to avoid being influenced by the implied necessities of “edges,” at least until they are formally specified. At that point, we can evaluate data structures that meet all the previous requirements, plus any new ones.