The 'ticking' property of 'container parts' sounds like a useful guarantee for reasoning about async computational graphs (sections 3 - 4). So leaves have to be a function that returns, but containers can sit around listening for inputs. I've been struggling with the compositionality of String -> String functions for expressive social simulation. This sort of control flow architecture will help.

in general: I consider units of software to be more primitive than “functions”. A Part is ready to run if it has any messages in its input queue. When it is chosen to run, it might produce zero or more output messages and queues them up on its output queue. The Container routes the output messages, then loops around again to check if message routing has caused any other child parts to become “ready”. It does this over and over again until there are no inputs on any child queues and there are only messages queued up on its own output queue. I call this repetition “ticking”. Operating system Dispatchers() do this, but they set a timer to interrupt a long-running child and to return control back to the Dispatcher(). In the PBP case, one is simply building a program, so preemption isn’t required (it’s “just a bug” to have a too-long-running part), hence, we can whittle away a lot of hardware and CPU cycles and make the whole thing more “efficient”. … back to my use of the word “function” - “functions” imply a hard-wired routing policy, i.e. callee must /always/ send info back to the caller. I contend that it is important to be able to /not/ hard-wire that routing policy in /all/ code. IOW, a “part” is something more-primitive than a “function”, in my mind.

I'm seeing the distinction between Containers, Parts, and Leaves more sharply, thanks. I agree it's a good idea to eradicate 'function' in this context b/c it could mean either an ideal function (with no stateful beliefs like the input/output queues), or a function on a call stack (which drags in conventional imperative beliefs about the runtime).

I'm not sure what the utility of more than one Container is.

Architectural layering. Isolation of data /and/ control-flow. LEGO®-like parts that snap together. You can create a large system which is simple enough to understand at every layer. “Functions” promise that kind of composability, but, the underlying “blocking” nature of function calling (caller must suspend waiting for callee) hampers pluggability. In my eyes, current software practices based on code libraries lead to bloat and to fragility and increasing complexity and to gotchas. Analogy: the “ideal” way to build programs would be to create multiply-threaded architectures and use 1 Arduino (or other small machine) for each thread in a program (i.e. no operating system or other bloatware needed). If I were to build a system like this with 1,000 Arduinos, I’d find some way to group them in a hierarchical fashion (think ORG chart in business, and, middle-management) and this leads to “multiple Container” thinking. This is what most programmers think that they are doing, but, I contend that they are not because of the hidden gotchas that function calls/returns entail.

Thank you for the idea of a "wire table" -- might have just knocked loose some things I've been stumbling on in my head.