I Wrote A Programming Language – While

“While we wait for life, life passes”- Seneca.

I am developing a programming language, currently codenamed Goblin.

It is heavily focused on set theory and draws on ideas from graph databases, with a factory-oriented design.

The goal is to make it possible to build graph-database-style node-and-record structures, then adapt them to represent larger object structures, networked records, lists, graphs, and more.
I would hope this language sort of exists at an intersection of different languages and might be a bit of an experiment in design.

My original principle was that these capabilities should be expressible directly in Goblin—not merely through a function call that returns a list. This would allow developers to create novel ways of organising data, naturally produce indexes, and define data structures that do not exist in other languages.

I did not want to create bespoke functions or data structures; I wanted users to write code that defined the structure themselves, enabling more creative database design beyond simply defining fields to be indexed. I wanted the ability to write descriptions that order data and define indexes.

That proved more difficult than I first expected, which is why this section is called “While” rather than “Data Structures.”

I wrote a While loop in a query language, then I used it as a jumping-off point to explore folding the database up.

Order In Data Like Protein Folding Not Like Calling A Function

Conventional languages provide a set of data structures out of the box. In C or C++, you can rebuild them from more primitive constructs—direct bit-level control, structs, and pointers—but by then you are working close to the level of assembly language. Most languages instead say, “Here is a list and a set,” then debate whether an unordered map should be called a dictionary or a map. You build your objects from those pieces.

Goblin works differently. Everything is a series of nodes, with a query language for finding those nodes and a system for linking them into a network diagram that describes how records relate to one another. Rather than incurring the overhead of joins, Goblin creates a graph: related records may live in separate memory locations, but each record knows where its related data exists in memory. This makes access very fast.

The current limitation is that each relationship must be declared individually. It would be more useful to define rules for connecting two nodes, then allow a function to apply those rules and link the data automatically. In a sense, lists, trees, and maps are all forms of graphs—although maps are perhaps less obviously so, even if many use B-trees internally.

The limitation in SQL is that keys must be defined and uniqueness then protected, and then you have to do joins to link up data using those keys.

I liked the idea of you writing code that defines an order in which you move through the data; it could fold up data across the database in interesting ways. What I want is code that can build lists from graph nodes. By selecting an order and a processing strategy, you could create a structure that determines how data should be retrieved—recreating SQL-style scans and indexes while also supporting linked-list behaviour in Python or C++.

I also liked the idea of overlaying multiple lists, allowing relationships such as “go to the next highest date” or “go to the next highest income.” I took inspiration from biology, where a protein begins as a long chain of amino acids and moves down an energy slope, connecting at specific points where chemical bonds become stable. We often describe computing as complex, but beneath the surface, most systems are some form of list, tree, or network.

If you could write a function inspired by protein folding—one that follows an energy calculation to connect a dataset—you might achieve better performance. Currently, I create partitions for object-oriented groups and functions, with logical and table-based groupings that support behaviours such as full table scans. But you could also create relationship tracks: following them could behave like using indexes, or like folding a database so related data exists close together. I call this idea database origami.

Required functions to provide

I decided that, for this to work, I would need a few helper processes. I spent a long time thinking about how iterators process data and why query languages do not offer something similar.

I would need a while function that continually processes and reprocesses data until everything has been handled. At first, I thought this would be relatively straightforward: sort the data, pull out the top value, and recursively call the function to connect it to the next value. Then I realised there are several ways to build an iterator that moves through data one item at a time. At a minimum, it requires two objects when the data already exists as a sorted list, and three or four when it does not. This creates a chicken-and-egg problem. In many programming languages, the list object already exists, so iteration is rarely something you need to consider. Building it from scratch, however, requires a while process to test the object, a larger query to determine what comes next, and a third process to determine what to connect. Together, these allow the data to be traversed one item at a time, even when no iterator object already exists.

The goblinoid method works like this: it creates a while process that defines which data to examine, filters that data to identify the next node, and then connects it to the node that follows. In theory, this design pattern can be expanded to create a wide variety of custom node and edge data structures.

while {name=='alice' ! .next_alice} {name=='alice' ! .next_alice alias .max 1 connect next_alice {name=='alice' ! .next_alice alias .max 2}}

I realised I needed max and min functions that could move through the “energy values” by analogy. In other words, I needed to retrieve not only the next highest or lowest value, but any value at a specific position in that order. The .max and .min functions do this: the number that follows specifies the depth. For example, max 1 returns the highest value in the dataset, while max 2 returns the second-highest value.

The ! .next_alice condition removes data that already has the next_alice relationship. As a result, the remaining data is added to this list from the wider pool of records in the database. In SQL, you would typically search table A, then retrieve related data from table B and join the two. In Goblin, you can create a custom index that begins in table A and points directly to a value in table B. To retrieve the next record, you could call the next relationship again from the new record. This could support a range of web-development use cases and AI agents, allowing an AI to move between records as though following web hyperlinks, without needing to perform joins.

The initial setup for this web of links is still computationally comparable to building those joins. However, because the approach combines elements of indexing and joins—and can persist once built—I believe it is more flexible overall. Ideally, you build it correctly once, then write code to maintain the index as new records are inserted. I have not implemented that maintenance step yet.

A double linked list is probably more expected. A ~ command can then be used to move back and forth along the list. Should also look at a command to cycle X steps along such a path.

Binary trees probably should not be allowed to take existing data but add on new nodes alongside to represent the indexes to an existing state, then look at a value and split up to do 

1 read to check if me the value looking for, 1 read to check value see if > or < than value to determine if goes left or right which is another read and then a third read to transfer to the new location. Requires a factory that does this.

Map already supplied with global. Create a mapping location system that takes a set of data and links based on a variable, then orders by key or sub value.

I also added a simplified print that,t if you do not tell the language what data you are selecting, it just prints out data a bit like JSON.

I highlighted the inputs in yellow.