Distributed Reactive Programming for Claytronics
July 9, 2019

Programmable matter turns allocation into geometry. A distributed language must choose not only how much computation a program receives, but where that computation lives, which neighboring material it can influence, and how multiple owners coordinate one moving physical structure.

Every Resource Has an Address in Space

malloc() usually chooses any suitable address. fork() usually lets the system choose a processor. Claytronics needs another contract: allocate this region, at these coordinates, beside these neighbors, for this local behavior.

Physical position affects communication, force, motion, power, and the shape a collection of catoms can form. The language therefore exposes location as a computational resource instead of hiding it behind a scheduler.

Ownership Turns Contention Into Cooperation

Two people can move one box efficiently when each takes a side and both agree on the direction. Two programs need the same clarity. One owner may control the left region, another the right, while a shared protocol coordinates the seam between them.

The system tracks whether a region remains available, reserved, managed, damaged, or lost. Those states let local programs adapt without asking one global controller to understand the whole physical object.

Code and Material Share One Vocabulary

When code and data use the same reconfigurable material, resource type becomes homogeneous. Geometry, ownership, availability, and current configuration distinguish one allocation from another. Reactive updates then move through local relationships as the physical structure changes.

Florian Myter’s underlying-layer work supplied one starting point. A high-level language can build above it by making spatial agreements composable and visible.

Build the Next Layer

The next opportunity lies in a language that can reserve regions, transfer control, recover from lost cells, and coordinate motion across many local owners.

Originally posted on LinkedIn

Brian Greenforest · (2019-07-09 05:12:08 UTC)

Open the original LinkedIn post · LinkedIn activity 6554225491195371520

LinkedIn status when archived: Visible to anyone on or off LinkedIn.

Designing a distributed reactive programming language is the major stepstone on the long path to scalable Claytronics (programmable matter). Resource allocation could (and should) be made explicit in a distributed programming language. When programmer is aware about exact size and locations of available resources, efficient management of these resources becomes possible. Imagine allocating chunks of memory in malloc() not only specifying size, but exact address, where the chunk should be allocated. Imagine calling fork() and specifying exact core (or even remote location). In our computing model, code is data, and data is code, so the type of resource is homogeneous. Only geometrical physical location is left, and the fact that the resource is available / managed / or was lost etc. A great work was done by Florian Myter on the underneath layer https://lnkd.in/gwSU_Q4 We need to explore high-level design for the language where distributed management of resources can be agreed upon over shared access to areas of influence. Imagine working on moving boxes with your friend. You can agree that your friend will be moving the left part, and you'll be moving the right part. Without the agreement, you experience a lot of "resource contention"...