A chart is a dataflow program written in a piping style. Where UNIX might call for 'a | b | c', we write 'a b c'; we show nodes, but edges are implicit. Semicolon is a parallelization operator; it represents the copying of the input data: in 'nodeA (nodeB ; nodeC) nodeD' user input passes into nodeA; nodeA's emissions are sent both to nodeB and to nodeC; their emissions are merged and sent to nodeD, the emissions of which are produced as output.
The data, as it passes from the left to the right, is called a flow. The flow is split by a semicolon and merges at the end of scope. A flow contains many named channels. One channel carries a single data element, of any type. Strictly, a channel is a contract between nodes that emit on it and nodes that listen to it, defining how data will be passed. A stream is a unity, so any channel may be a stream. (In the present implementation, every channel is a stream.)
Nodes are reentrant and stateless, substantiated on the arrival of input. Because a stream is a unity, the node maintains state until the end of the stream, but this behavior is incidental -- the node is persistent due only to the data's persistence.
If a node ignores a channel, that channel will continue past it to be connected where it is needed. Renaming and namespacing operators are proposed to help prevent name collisions. An entire flow can be namespaced into a single channel, and a node can be executed within the context of a single channel.
A chart is a valid node. That is, if we have: chart1='nodeA (nodeB ; nodeC) nodeD' and chart2='node1 chart1 node2', this latter is equivalent to chart2='node1 nodeA (nodeB ; nodeC) nodeD node2' by a simple substitution rule.
The Python implementation of a chartrunner is meant to allow immediate use of a chartrunning system and to be changed easily as experience dictates. There is no plan to use channels as anything but streams, but distributed computing will be supported. To distribute a chart, the full (net-unaware) program can be shared. Each machine can automatically produce a networked version of the chart by replacing a subset of nodes with networking nodes. 'a (b ; c) d' might become 'a net d' on one machine and 'net (b ; c) net' on another; alternately, 'a net' on one machine, 'net (b ; c) net' on a second, and 'net d' on a third. In each case, the 'net' keyword must be fully qualified with address and protocol.
Charts can be interpreted in one of two styles: the imperative style (presently in use) and a declarative style. In the declarative style, a node represents both a test of a relationship and a fix if that test should fail. This differs from the imperative style in its keeping of state; state is maintained on the channels (not in the nodes) and changes in state propagate through the chart as dataflow. Such an approach might be appropriate for application programming, and particularly for user interface.
If channels carry access locks then a chart takes on an imperative procedural style. This way of thinking may help programmers transition to use of a distributed methodology. It also suggests the possibility of a purely chart-based language.
These details are provided for information only. No information here is legal advice and should not be used as such.