I think that this might be interesting to FoC’ers because: it demonstrates various techniques (t2t, 0D, feedback with queues, etc.) that aren’t common in Functional Programming. These techniques might inspire ideas of what is possible in the FoC realm, beyond the usual more-programming-using-only-the-function-based-paradigm. I, also, believe that VPLs and DPLs are ignored for at least 2 reasons: (1) it’s believed to be very hard to parse diagrams, and, (2) text says it all, what more could there be???. This progress report quietly attacks both mis-beliefs. (1) Parsing diagrams - in 2024 - is sooo easy that even someone like me can do it. (2) Feedback loops and structured message-passing produce efficient ways to express certain idioms that can’t be expressed - easily - in textual form, hence, are roundly avoided, hence, causing inadequate simplicity of design in certain problem domains.

One thing that I keep forgetting to mention, is that even though I appear to be drawing node-and-arrow diagrams, nodes contain input and output ports. Possibly many of each. In contrast, functions in FP, have exactly 1 input port and exactly 1 output port (modulo the wart called “exceptions”. So-called “multiple parameters” to functions are but an optical illusion supported by destructuring operations (it’s all just one block of data that all comes at the same time, regardless of how you want to slice-and-dice the block)). Arrows can only be drawn from port to port, not from node to node. This simple concept of ports provides high levels of encapsulation of data /and/ encapsulation of control flow. Nodes are akin to Actors, except that Container nodes can be recursively defined to contain other Container nodes. Akin to the idea of Lisp lists containing atoms or, recursively, lists.