erlang ! hello

On Tuesday while reading Programming Erlang on suggestion of Andreas Cardeneo from the Research Center for Information Technology of the University of Karlsruhe, I started to experiment in Haskell with typed channels and lightweight threads to imitate Erlang style processes and networks thereof.

Here is the very early and raw code from a few hours of exploration.

And here is a simple interactive session in which a server is created that reads strings into integers. These integers then get _distributed one at a time_/_dealt_ to a first layer of 3 parallel nodes and they then travel to a second layer:

*Erlang> (server,out) ← serve (read :: String → Integer)
*Erlang> l1ts ← create 3 :: IO ([Chan Integer])
*Erlang> did  ← deal move ([(\y → y - x) | x ← [1..3]]) out l1ts
*Erlang> l2ts ← create 3 :: IO ([Chan Integer])
*Erlang> tids ← sequence $ zipWith (link move (2 *)) l1ts l2ts
*Erlang> server ·· [ show x | x ← [2..4] ]
*Erlang> all_ flush l2ts
-- [[2],[2],[2]]
{-
   FLOW VIEW

            l1    l2                     
            ---   ---
             1  →  2
in    out   ---   ---
---   --- ↗    
"2"    2    ---   ---
"3" →  3  →  1  →  2
"4"    4    ---   ---
---   --- ↘    
            ---   ---
             1  →  2 
            ---   ---

-- before "all_ flush l2ts" actually only l2 is not empty

   ACTUAL STATE

            l1    l2                     
            ---   ---
                →  2
in    out   ---   ---
---   --- ↗    
            ---   ---
    →     →     →  2
            ---   ---
---   --- ↘    
            ---   ---
                →  2 
            ---   ---
-}

one could use such a system to distribute, say, processing of images to multiple parallel threads that utilize different cores or processors on a single machine. Using copy links (link copy ...) instead of move links (link move ...) would leave copies of the intermediate results on channels and we could see into the individual stages of a complex image manipulation. Tagging messages that travel between such processes would make it possible to divide a problem into pieces and process the pieces in parallel and put the results back together. One could make the inter-process communication lazy and declare a process network structure that produces results only when there is demand from the terminal nodes.

Check out this link for more examples of different process networks!

As I write these lines, I don't know if there is any prior Haskell work about such things but I could imagine this or a more serious endeavour turning into a nice little framework for distributed processing. By using more advanced primitives for communication than forkIO and Chan a, one might span a process network across machine boundaries.

In this blog post, 'process' means "a lightweight thread that reads from a channel and applies a function on what it has read and writes the result to another channel" and NOT "OS process".

This protoprototype of process networks has not been performance-tested in any way. This is very much an experiment and further investigation of the concept may or may not turn out to be useful.