Last Wednesday, I redrew the fibonacci diagram. I think its a bit more intuitive now. I will upload it later.
In other news, I have a Qt-based editor under way. Once this is usable, I can start working with more complex example diagrams, so this should be interesting. Also, when the editor is at a usable-enough stage, I’ll finish the VM and maybe release a prototype for people to play with. I’ll see what happens.

if this condition true then use this box of outputs
if the next condition is true use this box, etc etc etc.

would basically combine ‘if’, ‘case’, and if you do it right, you could make it work with pattern matching as well.

Yes, I imagine you would write a component which takes only one value and initializes the other two inputs to 0 and 1 respectively.

am i missing something here?

You’re right on the mark. This is the exact reason why I stated that this is a crude first example which can still be greatly improved. I wanted to start simple though and slowly move towards my ideal implementation.

The biggest flaw with this version is, like you said, that sending a message will still call the function from the other components. This was only done to keep the implementation simple. What I would really want to do, in the send function, is to queue the message to be processed – not actually process it right away. This means that components can (and I believe actually should) be run in separate threads, either one thread per component, or a pool of threads where each thread can processes one or more components sequentially. This, potentially, allows components to run in parallel and also, depending on how messages are managed and passed to the receiving components, would also allow them to run in seperate OS processes or even on other machines.
My goal with this system is definitely to allow components to be added and removed from a system dynamically, at runtime, without breaking the rest of the program – as well as allowing for the possibility of running components on different machines.

Messages should be immutable chunks of data which get sent into some magical cloud, which then passes them to the components. No components calling functions of other components or anything like that. This magical cloud is an execution manager which does have access to the components, but it shouldn’t directly access them either, but rather add the message to a queue. The component should then process it as soon as its ready to do so (the execution manager makes sure that it gets run – or if each component has its own thread, then it will manage itself). Because calling other components only happens through messages, I see no reason that they cannot be sent over a network, or whatever you want to do.

This implementation doesn’t allow you to do these things easily, but my goals with this post were more to introduce the idea and provide some simple code to play with. I think this code is simple enough that people should be able to grasp it right away. I do intend on improving this code, though.

As for dataflow, for the moment I’m treating it seperately from this stuff. Eventually I’ll unify all of the concepts under a single system/language/framework.

Regarding grouping of functions inside components, this is something I had thought about a few years ago, in relation to developing operating systems. The idea was to more-or-less NOT provide any functions – to implement a function, you must implement a message handler. To call a function, you must send a message. I do see this as the way to go, but for a C++ implementation, theres obviosuly nothing stopping you from having each component be a stacked hierarchy of fucntion calls. This has the flaw that theres no obvious means of knowing how much any given component should contain – a flaw which you pointed out, in your blog, that dataflow does not have.

I had this implemented a while back, but unfortunately I lost the code due to a disk failure. This version had a pool of one or more threads, which would process components. Each thread was the exact same and could process the same components. The event manager was responsible for creating events from a memory pool. Events were extremely cheap to construct and destroy, so there were no issues with communicating only over events. The only locking code that was needed was to access the queues onto which components were placed when they had an event to process. Everything else was completely lockless. There was some complex code in there, but overall, it was a pretty simple system. It worked very well and I was planning on turning it into a small game engine. Unfortunately, the disk died and I lost the code. Lesson learnt – always back up code! Oh well, the next version will be much better!

Here are a few things you may want to consider if you want more flexibility even though the initial setup of this system is a little more complicated.

First is that components should never execute anything in another component except to store a message. But at no point can this call another function to process that message. If the other component has its own thread, then that thread can process it, otherwise you need to wait until the component is completely done before starting up the other component that received the message.

Second is that you need an execution manager. Either all components have their own threads, or you can have a separate function that executes each component in turn that have messages waiting in their queues (you could even have this threaded as well with locking mechanism in place for the message passing so that each core can execute a component).

This is just me, but the true meaning of flat hierarchy is one where you can move a component (or sub-component) anywhere, even to another machine. Or where you can group them together into compound components. If you include a call to send which then processes that event in another component, you lose the ability to group or separate. They are forever coupled to each other.

IOW, (again for me) a flat hierarchy is where we, as humans, can group or separate components, but where the machine(s) can NEVER make use of this to execute the code.

You may have different plans and your example is certainly the right way to go for an example as it contains all the prerequisites before going to a dataflow model. All it needs is a modification of the send routine so that components can queue incoming messages and a component queuing mechanism for a kind of round robin execution handler (components get inserted into the execution queue when they have a message in their incoming queue).

To reiterate, flat hierarchies are useful to me because they allow the developer to create arbitrary groupings anywhere in the software that help visualize the software in a more comprehensive fashion (higher level). But where those groupings mean absolutely nothing (other than perhaps substituting the implementation) to the execution manager, enabling code to be automatically distributed. So developers get to see the “big picture” or small details as they wish without adding extra complexity to the runtime (once it’s set up) which allows it to do automatic distribution.

What do you think? What are your views on flat hierarchy that make it interesting?

Here’s just one example of an advantage that I see. When you group functions together into another container function, you’re essentially grouping not just the functions inside your container function, but also EVERY single function that is called at all depths of execution. That’s a stacked hierarchy. A flat hierarchy allows me to group together only PART of the depth. I could group ONLY the first function calls, but not the second level of execution nesting. Of course, that makes no sense in normal C++, but it does if you create components with the two added points above because components are individual entities. This would allow one to create libraries that not only gets called, but also that connect to other components on the other side. IOW, you could use libraries ANYWHERE and for ANY amount of code. Right now, macros and templates mostly serve this purpose, but obviously the need is there.

Am I off base with what you are thinking about? Those are some of my views. But I’d like to know more about how you’re going about it. How do you see this being used?

(And apologies for the long comment.)

I´m off for a run after this tea, so chat laterz maybe!

Speaking of agent-based modeling, I know its incomplete, but check the previous blog post. The entity system approach seems like a powerful way of simulating an environment and its interactions, potentially.

Anyway, ping me on google talk, if you want.