PBP Part Basics

2025-09-07

Sep 07, 2025

A part is a black box with input ports and output ports.

Data - and only data - can flow into input ports.

Data - and only data - can flow out of output ports.

A scheduler determines when a part can run. This is different from what happens in most modern programming languages, when a function calls another function. The calling function pauses (blocks) and expects the callee to run and to return a value which finally unblocks the caller. In PBP a part can send mevents to an output port, but this does not block the sending part. Functions in common programming languages leak control flow because of blocking. Parts are pure dataflow, parts are asynchronous and do not leak control flow. (Mevents are just event-causing, tagged messages).

There are two kinds of parts:

a Leaf Part that contains code
a Container Part that is a little, recursive scheduler that contains parts and wires between the parts that it contains.

We can create Leaf Parts by writing code. We can create Container Parts by making a drawing and compiling it down to a JSON graph. Currently, I use drawio to make drawings and a small program called das2json to compile Container Parts to JSON. Currently, I use languages like Python to create Leaf Parts and, I use a custom language that compiles to Python to create the PBP kernel and stock leaf parts. I created a custom language for the kernel because:

it was easy to do using OhmJS and T2T
It allows me to avoid writing Python code explicitly.
The custom language compiles to several other languages, so the kernel is portable. Currently the other languages are Javascript and Common Lisp. I haven’t tweaked the custom language to emit other languages, but I expect this to be a fairly straightforward task needing only a few hours for someone who is already familiar with the target language(s).

Experience

Currently, I use a makefile and/or a shell script to make a system by bundling up the Leaf Parts, the kernel and the Container Parts. The system then runs like any program. Currently, I use Python as the host language because this choice makes experimentation easy. We used to use Odin - a non-garbage-collected “systems programming language”, essentially a modernized C or C++ - so these ideas are demonstrably portable to a wider range of host languages.

I’ve built examples of using PBP in a browser, with Javascript as the host language.

I’ve built an example of building a small PBP system using only hand-written Python code, without needing to draw diagrams.

I’ve used PBP and T2T to build systems using multiple programming languages. In one case, I bolted Prolog and Javascript and bash together.

Relationship to Pipelines

On the surface, PBP, is much like UNIX pipelines. The difference is that PBP allows fan-out and feedback (feedback and recursion are two different things semantically) and, in PBP, all parts are asynchronous by default, whereas one needs to use the “&” operator in bash to break implicit sequential behaviour. On the surface, it might sound like PBP is more complicated to use because of default asynchrony, but, I find that it is easier and less buggy to use PBP for many problems that aren’t basically calculator-like.