2024-06-14-Connections are Triples

2024-06-14-Connections are Triples

Overview

We want to draw software as LEGO® blocks in node-and-wire diagrams.

We want to be able to rearrange the architecture of the software by rearranging the drawings, eg. to move blocks around on the diagram and to connect the blocks in different ways.

To maximize flexibility, we must:

• Make the blocks of software be fully isolated and independent of one another. I call this “0D” and discuss it elsewhere.

• Ensure that the blocks do not know how they are connected to other blocks. To do this, we must ensure that the connections between blocks are not owned by the blocks themselves, but, are owned by the parents of the blocks.

This second point - ownership of connections - is the topic of this essay.

Connections

See the following sketch and note that some parts are coloured in green, while other parts are black.

In this sketch, the green, enclosing block is “the parent” block. From the outside, it looks like any other component - it has inputs and outputs. Possibly more than one input and possibly more than output. Maybe zero inputs or maybe zero outputs.

In contrast, textual functions always have exactly one input and exactly one output¹. Function-based notation has one sweet spot: describing computations and equations while ignoring physical aspects, like time. Function-based notation is inconvenient for expressing programs like daemons or sequencers, such as DAWs and video editors, since these kinds of programs involve timing, and, produce multiple outputs over time, and, accept multiple inputs over time. You can express these kinds of things using function-based notation, but you have to invent work-arounds since you are abusing textual notation and pushing it out of its sweet spot.

In the above sketch, information - in the form of messages - flows from left to right, as indicated by the arrows.

To keep things flexible, the black blocks cannot know where their messages come from, nor where their messages go to.

Message flows are specified by the enclosing, green, block.

In the sketch, we see three kinds of message flows:

• down from the input of the enclosing container’s input

• across from one black block to another

• up from a black block to the output of the container.

There is a fourth kind of connection that is not seen in this sketch. It is the through connection from the input of the green container straight through to its own output. That kind of connection is useful for stubbing out container blocks, i.e. not bothering to specify the internals  of a container, leaving such details for later embellishment.

The container - the green block - is a composition of other blocks, maybe Leaf blocks containing code, or, maybe Container blocks containing other compositions. You can’t know by looking at the sketch. You don’t need to know, as long as each block does what it promises to do. If you really, really want to know what’s inside a block, you can use the diagram editor to dig deeper into the internals of the block.

From the above sketch, we see that a Container holds two kinds of important information:

• A list of other blocks. The “children” of the Container.

• A list of connections - routings - between the children, and, between the Container and its own children.

Connection Triples

A connection, then, is a triple, which looks like:

• A direction - down, across, up, through

• A sender - a child block plus its output port. Or, the Container itself and one of its input ports.

• A receiver - a child block plus its input port. Or, the Container itself and one of its output ports.

To illustrate, let’s label the children and all of the ports, say...

So, C has one input port ‘1’. C has one output port ‘9’. Child X has one input port ‘2’ and two output ports ‘3’ and ‘4’. Y has one input port ‘5’ and one output port ‘6’. Z has one input port ‘7’ and one output port ‘8’.

The connections - specified and owned by C - are:

• C1 down to X2

• X3 across to Y5

• X4 across to Z7

• Y6 across to Z7

• Z8 up to C9.

See Also

References: https://guitarvydas.github.io/2024/01/06/References.html

Blog:

https://guitarvydas.github.io/

Blog: https://guitarvydas.github.io/

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/Jjx62ypR

Leanpub: https://leanpub.com/u/paul-tarvydas

Gumroad:

https://tarvydas.gumroad.com

Twitter: @paul_tarvydas

1. The textual representation of functions makes it look like functions might have more than one input and more than one output, but, that is just an optical illusion. The single input is specified by a parameter list, usually shown as typed identifiers enclosed in parentheses, like ‘(a : int, b : string, c : float)’. This only specifies how the single input is destructured into apparently distinct variables. The input is but a single block of data that contains information of different kinds. All of the information of this kind of input must arrive at once, as a single block of data. Likewise, outputs are clumped together into a single block and destructured by the caller.