Imagine now that you want to work with an undirected graph. The setup made within weave is very digraph-oriented. In my experience, directedness is easier to ignore than to implement from a basis in undirected graphs. This leads us to the following questions: do we need to have a structural construction of a bidirectional arrow/undirected edge, or can the whole thing be made of different operations on a single, normal arrow, disregarding its direction and going the other way? It all depends on your situation in the end, but the change should be given explicit context by the structure around it.

In the example above, the bidirectional mints explored in previous entries convey our intent to have a sort of dual arrow that can be traversed in an endpoint-agnostic way that also supports normal arrow traversal. They aren't good for much more than exactly that. This structure, without any data (and remember that data is important because semantic systems query and operate on data!) operates to present the wanted semantics of an undirected edge. The operation used to traverse it (hop) is more widely applicable than the one for traversing arrows, so weave takes it as a ground truth, even though it’s one 1 primitive operation larger. If we instead focus on the solution where we just use raw dual operations on the arrows, we’re not supporting semantics through structure - we’re just doing things. Doing things is good, that’s what these posts are for the most part, but we need to solidify it somehow. With science!

A good first step after doing things is checking how general the behavior we’ve created is. Maybe it can be applied widely, maybe it can even be a new ground truth! If so, lift it up and let us all use it, that’s cool.

If not, create a named context. Contexts, although they still don’t exist in code, are all about named executive semantics - about how things are done when we run them.

For example, within your new as_undirected_graph context, running the functions arrows_in, arrows_out, and arrows returns the same set, as it ignores direction. This is what this context does to your execution. To have it affect things, it needs to be applied to a carrier structure, usually a hierarchy within which it will apply. Contexts allow interpretation, and a structured, limited, and explicit “reassignment” of ground rules.

Many ECS systems can be rewritten as contexts that execute their systemic code when some tag is added, for example. The first thing that came to mind is preparing a binary tree of operations and numbers within a hierarchy with an example eval_arithmetic context, and then attaching a “Calculate” tag which triggers the context to gobble up the tree and produce a single node. Having contexts be this wide and open allows for code lifting: taking what had to, until now, be written in code, and wrapping it in a couple of motifs, executed by an uplifter context.

If it isn't obvious, the idea of contexts fills me with joy. They solve many of the problems I initially had, such as the one that this post started with - contexts are usually marks added to a motif whose dependents now take peculiar shapes following peculiar rules, so they are in fact upheld by structure even though they themselves change algorithmics. Complex topics such as how to do transitive closures, operations with results, chaining of operations represented via motifs, requiring certain components to exist, as well as error reporting become easier once this tool is brought in. There’s a lot of open questions about the proper code introduction for contexts, which is mostly why they haven’t been coded up yet. I can already tell that contexts will change how most of weave works right now, meaning that they need to be bootstrapped somewhat recursively, a feat I'm not ready for yet. But we're getting there!

This isn’t the most intuitive, as we might want to find out where we can flow from a or b, and not see this arrow at all. To mitigate that, I’ve thought about inverting the arrows, but for some reason feared that this somehow breaks the mint. But, weave takes a lot from category theory, and the idea of duality always producing something correct even if useless prevails, so let’s try it. Here’s the two constructions side by side:

Basically, every source and target relation is reversed, and the result is familiar.

I confess that what we have here is more desirable-seeming than the original, if for no other reason, then for the fact that it’s a bit more welcoming for traversal from each end. The traversal itself is the mirror image of what we had before: this time, we take src(tgt(arrows_out(·))) and it produces desirable results:

src(tgt(arrows_out(a)))
= src(tgt([m]))
= src([n])
= [b]

src(tgt(arrows_out(b)))
= src(tgt([n]))
= src([m])
= [a]

The dual identities peculiarity from before is upkept: the target of each of the arrows is the other arrow, but their sources are coming from outside. If we have a normal arrow r = a → b, assuming that a and b are knots, the following happens when we use this construction to traverse it:

src(tgt(arrows_out(a)))
= src(tgt([r]))
= src([b])
= [b] ✓

This is, in a way, better than what we had with hop in the last post:

tgt(src(arrows_in(a)))
= tgt(src([r]))
= tgt([a])
= [a] ✕

It turned out that hop isn’t good at traversing normal arrows, but this new hop is!

Duality is a fast way to see if there’s more to a space. Sometimes, it turns out that the dual space of an already useful concept is even more useful, just as it happened here. Not all dualities are obviously useful, but it’s a great exercise, especially for something like what we’re doing here: I feel like I only have a budding understanding of what’s better when comparing two concepts. Here’s what that feels like…

If given two entities A and B, assuming that they offer similar answers to the same questions, I’d say A is better if there’s a shorter path to the answers, and one that is algorithmically more conservative. Since we’re working with graphs, algorithmic complexity is a tense question, so sprewing up more structure instead of data helps. That’s why knots, which are informationally redundant, aren’t optimal: they show that we’re leaning too hard into algorithms, and weave sort of promises that it might be best to try a different route. There’s an adjacent topic to this regarding whether more structure is necessarily more space as opposed to more time, which I think is very hard and not at all obvious. You know it’s bad when the main argument for why not is “there’s this thing in physics called time crystals, I think we should look into them”.

Let’s start with a familiar duo:

a = a → a,
b = a → b

We have one knot and one tether growing off of it. If we now mutate the knot’s target…

tgt(a) = b

we get a pretty unique thing:

a = a → b,
b = a → b.

I’ve chosen this one to be the woven tools logo because it was just that cool. These two entities are now codependent and have the same source and target as each other. For all intents and purposes, a mark and a tether shouldn’t be able to link in such a way, and yet here we are!

So what is this? I don’t honestly know, but it’s a good basis for a linked-list, with the new elements inserted as marks at the end of the red arrow and pointing towards b, while the blue arrow remains a quick way to reach the end of the list. This might just be my style but I’d also like one external arrow L = a → b, so that we’d have a singular entry point to this structure. Passing L around is easy, its source is the sentinel at the start of the list, and its target the sentinel at the end.

We can similarly turn the source around using src(a) = b, creating this:

There’s a cool space for shapes like these for dealing with equality classes, I think, although I yet need to explore it more thoroughly.

The original four shapes weave introduced — knot, arrow, mark, and tether — are called motifs. Motifs lived alone for a really long time. Years, in fact. These stable self-recursive structures are only days old in comparison, and I don't even know how many there are, in comparison. They seem super useful even in their infancy and I asked my friend, Darinka Zobenica, who I keep pestering with these things, to come up with a name for these self-referential thingies she noticed. She came up with mints and it stuck! I think mints are a stroke or genius on her part and pure good luck on mine, to have bothered her with this topic.

A much greater wealth of shape

Mints are an indicator, for me. A canary in a coal mine, the imprint of the rigidity of my own baby steps into this domain. The combinatorics of identity, source, and target delivered motifs and in isolation, these are the building blocks of these identity relations. However, in many cases, the minimal form of a pattern doesn't deal with the nothingness that a knot represents. I almost feel that knots, even though we're used to thinking of them as graph nodes, are just stepping stones or prototype-entities that can be there to give us some time and material to mold them into something more useful.

There’s a strange calculus behind what’s “useful” in weave, however. For one, there’s a certain “goodness” in direct source-to-target traversals. What I mean by this is more visible in an image. Compare these two scenarios:

Above, we have a standard knot-arrow-knot system we’re used to for making graphs. If we want to traverse this starting from the left, we can’t just follow a to its target — the target of a knot is itself! So the traversal of the above graph would be stuck there on the left for a really long time. To get to the arrow, we need to go outside the a entity and into the storage of sources and targets, looking for any entity t such that src(t) = a. This isn’t a huge operation if implemented as it is in weave - we’re using a bit of extra space to keep every dependency hashed, so that we don’t have to go through the whole storage, but it still feels like a chore.

Compare it to the second scenario: if we trace x to its target, we end up with y. if we trace that to its target, we end up with z, and are now stuck here. We’ve just traversed the whole thing left to right. This lovely power of transitivite flow is only lessened by the fact that you need to keep it simple with structures like this: because the flow is a part of the definition, each and every one of these pieces is uniquely and fully defined. We can’t attach new arrows here, we can’t have multiple paths. It almost seems inviting: maybe we shouldn’t be looking at weave at this low-level but rather one step above where the shape will automatically optimize itself if it recognizes there’s no need to do a more demanding operation, and deoptimize itself in case one is needed. There might be an optimal usage for knots outside of proto-entities, but given that mints are a good replacement that guarantees cascading deletion, I think they won’t show up much except for boundary objects - objects that are to be sent across especially agressive boundaries that don’t share structure well (between languages, processes, etc.)

Scenario two here is very interesting because it’s similarly self-referential as the mints above, but looks more “normal”. Both endpoints depend on the arrow in at least one of their endpoints, and the arrow uses both of them. To construct this, we have to go with:

x = x → x
z = z → z
y = x → z
tgt(x) = y
src(z) = y

In a way, this mutation is similar to lazy evaluation, which might be a larger and more important topic to talk about: another way to do this is to declare but lazily define pieces of the structure, like so:

exists x, z
y = x → z
x = x → y
z = y → z

If a language a bit higher up than weave would want to implement this, it would be trivial: simply make knots and allow full redefinitions to reuse the same entities. There’s probably a lot of material about the connection and possible equivalence between mutability and laziness, given that they’re opposing forces in imperative and functional languages, both of which are of the same expressive strength. I find it interesting that denying both of these makes a whole set of interesting and seemingly important structures be non-constructable… More research required.

How about bidirectional arrows?

Having mints that look like inwards made me think about the opposite: could we have something that closely resembles a bidirectional arrow? We could ever interpret it as a non-directed edge! This is a case where the math checks out, but I’m having a very hard time drawing this peculiar mint. Here’s my thinking:

Given some two entities a and b (we won’t ask that they be knots or something else), we start off making marks towards both of them:

m = m → a
n = n → b

Now, we change the sources of both arrows with the other one:

src(n) = m
src(m) = n

The current state of things speaks of two arrows, m = n → a and n = m → b, and this is, for sure, a mint, and one I can’t seem to draw… maybe something like this?

It still feels off, but it works. If you want to go from one end to the other, the action is as follows: if you start from an entity X and execute tgt(src(arrows_in(X))), you’ll end up on the other end! Here’s a sanity check:

tgt(src(arrows_in(a)))
= tgt(src([m]))
= tgt([n])
= [b]

tgt(src(arrows_in(b)))
= tgt(src([n]))
= tgt([m])
= [a]

Don’t mind the array-notation, weave explicitly tries to always expect that functions might return a whole array of things. This makes it easy to do closures, but also puts healthy pressure on the user to choose their own filters to get a single entity back if needed. I wonder what happens if we apply this to a normal arrow, let’s say z = x → y. Assuming nothing about x and y, we get:

tgt(src(arrows_in(x)))
= tgt(src([z]))
= tgt([x])

This is the last moment where we can assume nothing about x. If it were a knot or a tether, the result would be tgt(src(arrows_in(x))) = [x], meaning that this operation is at most an identity (and lift into an array). If it’s something else, then we’re pulled into whatever that other end is, usually the tail-end of a mark or arrow.

You’ve just seen the process of reifying new weave functionalities: it’s tiresome typing out tgt(src(arrows_in(·))) so we might just call it something like hop and call it a day! With hop and the biarrow mint above, we’ve potentially overengineered an easier solution, which is a biarrow complex construction such as:

The problem with this is that m and n are separate except through their endpoints. We could tie them with an arrow h = m → n or similar and pass that around, sure, but that would imply a direction between the two (equal) directions, which feels like a hack.

I like that the mint construction somewhat lost its sense of self while keeping it fully recoverable. Here’s what I mean:

other_dir(·) = src(·)

If we pass along m, other_dir(m) = n, and vice versa. Those are dual identities, they are both the source of each other, and both their targets are different! That’s enough to convince me that this is the way to go. We basically took two arrows and tied them together by their sources.

We’ll be adding this precious mint to the shape module, and hop to the traverse module soon, and who knows how essential it might be in the future.

So, first, what’s an FSM, outside of our models? It’s a graph where every node is a state in which the “machine” can be in, and the directed edges are available transitions between those states. FSMs introduce some special terminology: we have a current state, which is where the machine is at the current moment, and a starting state which is the one that the current state will initialize to when the FSM is made. In a way, the whole operational semantics of a FSM consists of moving over several values in a constrained way: to implement this, you need an enum and several ifs. It’s easy to see why any specific version is simple.

The semantics of a FSM has its source in the starting state and, at any given point, leads to the current state, which is constrained to the set of states we begin with.

Here’s a weave-centric way to build a FSM. Let’s say I expect a standard graph from the user. This is usually passed through to the FSM as a hoisted graph: a single knot with hoisted arrows to all the states. This format is what we do for many of the other functions that require a custom graph, but in this case we can use the fact that the internals of a FSM have more strict expectations: we want our states to be a finite set, uniquely owned by the graph. We therefore can ask for a single knot with all the states represented via tethers to that knot.

It’s worthwhile saying that the transformation of a standard hoisted graph G into a uniquely owned knot-tether graph is quite straight-forward and consists of taking the graph, going down the hoist to the member knots, making all of their sources be G, and then unhoisting them. All of these are standard weave functions, meaning that this operation is basically a one-liner. We can add checks to see whether any of the knots has multiple hoists leading to it, as we should quit early in these cases.

The Past and Present State

We’re currently taking care of the shape of the graph successfully, but we knew that we can draw a graph in weave. The question is what we can do with state and transitions. Initially, I found it very clear cut: we can just have a mark point to the current state, and one more to the starting state. The problem, however, isn’t in what we can do but rather how we can reach it at runtime. Starting with the top knot G, what do we have to do to get to the start state and the current state?

We could have these two be named arrows (arrows with some tag component) that lead to the states, for example. We could get to the current state by getting G and then asking for all arrows out, filtering out the one we want by component and getting the target of the arrow. In this regard, it seems start and current are isomorphic: the only difference in what data we set on them. Whenever I get to the point of things being equal up to data isomorphism, I know that we can weave further. For instance, let’s look at things functionally. The starting node should be the source of the state machine, we said previously, half in gross generalization and mid-hand-wave. But what if it was? What if instead of two arrows, we use the fact that the main knot G = G → G is… useless. What if we were to src(G) = start_node?

The main node G is now technically a tether of the starting state! Now, where does the FSM lead to? Well, our target always is to know in which state it currently is. So, what if we set tgt(G) = current_node? Let’s draw that first, without the image above, just to show off the idea:

Now, G is a mark of the current state. It is defined by its relation to this state in a way that allows us to always flow into it. Combining the two, we get a peculiar effect:

The source of G is the start state, the target of G is the current state. I’m doing you a courtesy by drawing the faint circle at the top but the truth is: the circle isn’t there. The entity G = start_node → current_node is no knot at all, nor mark, nor tether anymore. It’s an arrow!

The pattern that emerges from a FSM seems to be an arrow that keeps its source in the starting node (which allows us to easily reset it too by saying tgt(G) = src(G)) and moving its target around only where the thing that it points to can move.

The actual moving around

The implementation of moving around the FSM requires components, albeit in a very simple way. When we want to move, we find the set of arrows_out of tgt(G). We filter that small set by the virtue of them having a certain component we’re looking for, finding the one arrow we need (and doing nothing if there’s none, or even if there’s more than one), and then searching for it’s target and setting tgt(G) = tgt(transition).

It’s important to remember that any entity is just a simple object that can be the source or target of any other entity. If we want, we can even trace in-between states by moving the FSM arrow to point towards the transition. If the previous state was a node, and the current is a transition, we’re transitioning-in, and if we’re on an arrow and moving onto a node, we’re transitioning-out. We can do this from code, but just for argument’s sake, if we really wanted to, we could even draw this into the graph as an arrow from our FSM arrow G to the last target it had…

Why is it important that we can do this? Well, I’ve asked myself that for a very long time. All of this seems very dumb when compared to the state of the art in bitflipping and bytecrunching. We need speed, and we need minimalist design, and we need it now. Yes. But until it’s good enough, we need to be able to debug. We need to be able to visualize, we need to be able to understand, and we’re overwhelmingly visual beings. Creating a weave allows us to save this complex state as neatly organized ECS storage, and present it visually, and have it be simple to manipulate. After it’s done, it can strip itself bare until the only thing left is minimalist code, and even then, annotating the code with comments that carry weave identifiers might be useful for later, for some very late reconstructions. If you really wanted to, you could make a chain of arrows pointing back through the history of changes, and it would cost exactly one entity per step. It could be a very fun ride!

Any program’s language’s semantics consists of going from one state to another following some allowed transition. All language semantics fit the bill for a FSM, no matter how large. Every language looks something like the image above. If you can trace this for your small game, you can trace it for any other program, including the compiler itself. That’s primarily why weave is there for structured debugging.

Shape-generics

Side-note about a distinction that’s very nitpicky. For a while now, I’ve been keenly aware that we can represent any data structure in weave. It’s not a surprise — we learn it in schools after all. We draw state after state until it clicks, and then we transcribe it into pointers and while loops. The thing that interested me was that, more and more, as I’ve gone further into weave, I’ve got the distinct feeling that FSMs are less of a design pattern, and more a data structure. Weird, huh? Here’s my reasoning. If I have an array, for example, which is undoubtably a data structure, and I index it at 0 and get the value back, then at 1, etc. If I introduce a test for when to increment (or decrement) the index, I’m technically doing the same thing we’re doing with the graph in FSM. The only big difference is that the shape within the array and the conditions within the tests make the transition function of their graph far less transparent. The design pattern within the array-and-conditions would at most be how we use them, and not the array itself. I think it’s then fair to say that the graph itself in the FSM has far less to do with the pattern. It’s much more obvious what’s happening in it, but that’s just because it’s a better carrier for the pattern.

Furthermore, I’d say that we can say FSMs are a structure that in its operations encodes the above-stated behavior. Just as lists can be expected to return a head and a tail, or an array can be indexed, or a lock-free structure can be compare-and-swapped, a FSM can take a value, compare it to a limited set of values at its current location and swap locations if the test succeeds. This is one of its only defining operations, most others being getters for the current or starting state. The closest thing the underlying structure needs to be is a set of states and “labelled” transitions, corresponding naturally to a graph, but almost any graph will do. This means that we can say the structure accepts a family of different shapes. In type lingo, we say that it would be generic in this parameter, the parameter being structure or even more precisely shape.

We can make very clear preconditions for what a correct generic structure would be. For example, we only want arrows between nodes, we want all the nodes to be tethers to the graph, all the arrows should be tagged with either some one data component, or different tags, and no two arrows going from a single node should be tagged the same. This is still an almost infinite number of graphs that fit the structure but have different shapes. Within all of them, once we feed the starting node and specific shape to the FSM data structure, we can call the trigger method on it as if we’d be calling a pop on a message stack. The pattern is now all about how we use this FSM data structure.

If we delete “p” from the diagram above, “t” would be deleted as well, as it can’t “survive”. That might mean it gets deleted, but let's consider a less destructive perspective. If it isn’t deleted, we’d be left with a hole in our entity: “t = ? → t”.

We’d have to “pinch” it and turn “t = p → t” into “t = t → t” by being maximally conservative about our choices. This means that an orphaned tether becomes a knot! The same happens to marks as well, while arrows devolve into a mark or tether, depending on the missing endpoint. There’s a manifold of dependency growth and reduction here and it’s quite an interesting tool, especially if we’re viewing weave in a mutable context, where sources and targets can be changed over time.

Back from our detour, let’s now actually assume all dependents are deleted when their “parents” disappear. This gives us an incentive: if we can build using tethers, deleting the top-most parent deletes everything below it. This is great! In a way, we can build things with hierarchical structure and get cleanup for free. However…

Having a tether represent a child in a hierarchy is somewhat limiting: the fact it is a child or extension of something else is a defining trait for it. The identity of the parent is tied into it as well making tethers very similar to unique pointers: uniquely owned and held by some entity. This is only somewhat problematic: if you’re building a binary tree, it’s all good - all your “nodes” in the tree can easily be represented by tethers instead of knots.

Deleting a node high up the tree deletes the whole branch, and that’s good. However, if you want more loose hierarchies, tethers are only a part of the solution…

Before talking about the solution, however, let's look at one more problem because of which tethers are nicer for hierarchies than just, say, arrows with a “Parent” tag on them. Having tagged arrows be part of the meta-structure, informing us that some part of the graph is representing hierarchy instead of, say, transitions within a FSM, feels like lowering structure to data again. We can do it, we know we can, but it seems like having a chance to do something at compile time and then doing it at runtime anyway. Tethers aren’t arrows, they won’t be used for standard graph representation, opening up their use alongside knots (for nodes) arrows (for edges) and marks (for descriptors, eg. labels), as carriers of direct hierarchy.

So, if we have a graph whose bulk is represented using arrows and knots, to even add hierarchy, those knots that are “below” in the hierarchy need to become tethered to something above. If they should have two “parents”, tethers aren’t enough. We could make a single tether from the parent per node and add an arrow from that tether to the node itself, but we’re back to the issue of having “special” arrows. The solution is one step further: we extend a tether from the parent, and create a mark on the child. Both of these are “virtual” from the perspective of the graph, so we're cool! The only problem is that they're disconnected and nodelike on the ends that should meet. We need a way to bridge this, and in this case, an arrow would do the job quite well!

To recap, our parent entity p has a piece of itself extended towards some hierarchical entity c below it. This piece is its tether t. There's a unique relation r between this tether t and a piece of an entity below denoting that it is parented from above — a mark m. I call the tuple (t, r, m) a hoist because we've technically hoisted an arrow q = p → c that says “p parents c” into a layer of abstraction by saying q = t(p) → m(c). You reach out from p to c in a limited way. In other words, the between these two objects isn’t a defining feature of them, just a piece of what they are.

These three might seem excessive, but I’d wager that once it's setup in this way, this is the most general setup for hierarchies and will be sufficient without structural change for any number of further requests and design changes. Traversing a hoist is natural: every bit of it is oriented from the parent to the children, so just consistently moving towards the target of the current entity we’re “on” works in a way similar to the small (single arrow) and big (tether-arrow-mark) moves of a Turing machine. In Turing machines, big moves jump over a whole series of consecutive same symbols while small jump over a single one. In weave, hoists jump over levels of hierarchy while arrows traverse within a level. I'm pretty sure it’s a pointless simile in construction, but I can’t get over the fact Turing machines are in fact fully linear machines for which we need to plan and map out all the structures and moves in our ideaspace.

One of the most important long-term results of weave is to reduce ideaspace capacity, to create an environment in which one can almost geometrically construct ideas without the need to imagine all the scaffolding. Hoisting is an example where things seem to be much more complicated than they “need” to be — if a programmer was to mark a parent, they could just call the field or variable parent and have it all work by evening. What it does, how it relates to other things, etc. are important to hold in one’s head as one works, and then to hold in runtime memory as the program happens. In-between is what currently makes a programmer good in practice: if there’s a problem, how fast can it be solved and how much will the research take beforehand. Both of these are direct consequences of “how well is the problem mapped out in the programmer’s ideaspace?”. If we can even attempt to externalize that notion, we have a chance at lowering its upper bound, and ultimately, that upper bound is, in my mind, the source of most our problems.

I don’t really know. Sometimes I feel like idealistic programmers gazed into the abyss and the reality of a large, thousand-participant codebase gazed back and broke their ideals in a way that let them still worship them, even if depowered. Things need to be good enough in production, after all, and that means that we can have a lousy tile or loose screw here and there.

Other times, I think we focused on the large patches of wonderful fabric that we weaved correctly and gave that bit our time, disregarding the boundaries and transitions. Most bugs happen due to one boundary condition or another, and the hardest problems in programming always have to do with stepping over a divide: from the border between two languages that interfaces and types need to align and cross, to the externalization of intent that we apply when naming a variable, to literally defining a loop bound as a new limit of execution. Bounds are hard to execute correctly, and it’s where we don’t have structure, but rather a long list of infamous names… Foreign function interface. Byte array. Void pointer. Foo.

The idea for this whole topic of woven tools is to make something that a) doesn’t feel too alien to the current technological stack, doesn’t want to destroy it and start anew, but rather to infuse new life to it, and b) solves the issues of boundaries in a generic way, allowing ever more tools to sprout and come to life after a firm foundation is set.

Weave, kurzgesagt

In short, weave (aka libwv or just wv) is a library that underlies most of the efforts talked about in this blog. All the woven tools are presumed to have a basis in weave. In it’s narrowest context, what weave does is allow the distinction of data and structure in programming. Data consists of the many snippets of information that give us a full picture of some topic. Structure is how different, distinct data binds to itself - the shape it takes, the topological view of that information. Structure is, of course, only information, so it can be coerced into data. For example, a std::pair<T> in C++ is a “pair” of numbers, there’s a first and a second, but the structure of that pair is most probably simply a linear array of two, and the order of the two named elements is at best there to satisfy our intuition. We don’t imagine a pair of cherries, or twins holding hands, we’re seeing something that, as we’re getting closer to the boundary, shows itself to be the same as T[2]. If we call things a bit differently, we might find ourselves looking at a std::tuple<T>. The difference? Context, mostly.

This phenomenon is structure losing itself, becoming linear, enscribed into data. Nothing too bad— we’ve made a living out of it, after all, but it opens us up to a few questions. Did we go too far? Should everything be linearized in this way? We are losing some high-level structures, but they obviously never mattered, so why care? I say that they never mattered in the wide, open fields away from boundaries because everything is flat over there. We don’t mind boilerplate if it doesn’t increase complexity, and we hate complexity increases because they lead to bugs. Complexity can increase in two ways: data can be more complex, leading to more interspersed, diverse, linearly encoded strings, harder to parse and decode; but structure can be more complex as well, increasing the dimensionality of the whole while leaving space enough to breathe.

In essence, weave starts with a simple system quite similar to a relational database or ECS (Entity-Component-System) Framework. We have entities which are simple indices, components which carry data and are associated with entities, and then systems which is a group name for procedures that select, insert, query or otherwise manipulate entities and components. The structure we talked about above comes into play from taking a closer look at entities.

Instead of them simply being a single number, weave proposes us building every entity out of three numbers: an identifier, a source, and a target. We write “id = src → tgt”. The simplest motif built out of these have the same number for all three (id = id → id), and in this case, this is exactly the same as having only one number — this is an old-school entity in an ECS or an ID field in a database. I call these knots, to be specifically distinct from nodes. If we go further and create two of these called “a = a → a” and “b = b → b” (where “a” isn’t the same as “b”), we can now change it up and create “c = a → b”. This is a unique construction that weave lets us build and it looks pretty much exactly as you imagine it: “c” starts in “a” and leads to “b”, it’s an arrow.

With only this simple system, we can suddenly describe simple graphs without a single component used. It’s not surprising that we ended up with directed graphs, as they’re essentially pure structure. However, weave can go some extra miles as well: there are features to graphs that are usually just convenient that spring out of our three number system!

Because there's a component storage, weave let's us attach arbitrary data to these entities, such as a position on the screen, for example.

If, say, we wanted to have a label for our graph nodes, and we wanted the label to be rendered on the graph, we’re between a rock and a hard place. On one hand, we might want to add these fields (maybe, label_string and label_position) to all nodes, but adding them to a single large component seems crude and makes the component feel bloated. Adding separate components and then adding them all to the node and filtering what to draw and how can lead to some sticky situations with ordering and priority. We want the labels to be their own thing, with their own position reusing the same position component that the node itself uses, but we can’t just add a new node for the label and add an arrow to the original node, as that would change the graph!

We need to approach this structurally: the label is dependent on the node it's presenting for, in a way, it's pointing to it. If you follow it to it's end, where does it lead? The node. That's how we know the node is it's target. Where does it begin, though? Well, in the label. In itself. label = label → node.

This construct isn't nodelike, nor is it arrowlike; it's something of it's own. A pointer, descriptor, mark. I've settled on mark, as it's least confusing of the bunch. The opposite of a mark is a thing that grows out of something else that it's dependent on, but firmly forms itself in the process, a child = parent → child. These ones seem good for selecting, framing and tethering hierarchies, so I call them tethers. Much more on these two in future posts, they're quite important and useful.

All of these differently named entities are still just entities, and we can behave with them in the exact same way. We don't need to know what “a” and “b” are to make a “c = a → b”. Maybe both of them are arrows, which would make “c” raise some eyebrows, but it's valid. We can build a lot of stuff that is very practically useful but not at all immediately recognizable as a graph or any previously familiar structure.

So, it’s all about graphs?

I’d be lying if I said no, but also no. It’s about graphs because graphs are data points with connections, which is the building block of informational structure. But it’s the same as someone telling you they’re building the house and you asking if it’s all about the cement. Structure yields structure, and most of it is a graph of some kind when presented with sticks and stones. On the other hand, some of our problems would be simplified if we were able to turn them to sticks and stones while preserving their context. We do visualizations and performance metrics as an afterthought. Our debugging is mostly a complex mental model and some hexes and charms to stop the compiler in a convenient spot.

Graphs (and even more so, weaves, with all the freedom to mix and match shapes) can help. We need to stop using linear tools (like your favorite logger) and understand that the underlying complex structure is there. It’s just invisible below the boundary of our processes. I’m not here to make all the cool tools, but to talk about them and hopefully inspire others to weave them into existence.

Weave is a library for just that. It enables you to make weaves, knots, arrows, marks, tethers, but also to traverse them, search, pattern match, add and delete components, and build upon them. It’s written in Rust, and cross-compiled to C, with budding libraries for C++, C#/F#, and Javascript. I’m guessing you’re here to follow these developments, in which case, stay tuned!