While the concept of a cartesian program space is interesting, it seems largely unrelated to TNs. This is probably a good thing though, as programs require semantic relationships ("lines" between nodes) that are lacking in cartesian spaces. If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable. Otherwise the "dimensions" are just an irrelevant and cumbersome alternative to line numbers.
Additionally, a third dimension is meaningless as long as your fundamental representation is two-dimensional. Unless you use an editor that is natively 3-dimensional, mapping a two-dimensional representation onto three-dimensions will leave a lot of redundancy or sparseness, as demonstrated by your conflation of x and z.
> If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable
Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).
We are approaching everything simultaneously from the highest abstract level and lowest logical level. We have some more stuff coming out soon that shows off the benefits of the dimensionality more. One of the cooler experiments is a new type of processor with a graph-paper-esque 2D grid that can load a high level tree program and then execute it directly (no cumbersome series of transformations to a bunch of 64 bit registers). AFAIK this is original, though I wouldn't be surprised if Lisp Machines, Thinking Machines, Alteryx, Nvidia, Intel, et cetera have dabbled in this space a bit (though to date haven't been able to find anything on machines that execute trees directly).
> Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).
Actually, it seems like your tree relationships have a very confusing relationship to the coordinates. Adding a newline increments Y, and a space increments X, but children are those nodes such that that
1) child.Y > parent.Y
2) child.X == parent.X + 1
With additional complications that only the node with the lowest X value for a given Y becomes the child; all others on the same line become part of the content of that node.
This means that the relationships between two elements depends not just on their coordinates, but also the coordinates of nearby nodes. (6, 4) may or may not be a direct child of (5, 3); it depends on if (5, 3) is a full node, or just a content element that's actually part of (5, 2) or (5, 1).
So the coordinates do not actually define the relationships between nodes; they do not clearly relate to the tree structure at all.
> have a very confusing relationship to the coordinates
Agreed. I sometimes get confused too.
One rule that always holds is this:
1) One line === One node
So every node has an absolute Y coordinate (just the line number), but also a relative coordinate(s), relative to its ancestor(s).
Both are useful at various times. There's probably a better way to eliminate confusion here.
> So the coordinates do not actually define the relationships between nodes
Given an array of node coordinates {y,x} [{1,1}, {2,2}, {3,1}, {4,2}], one has enough information to define the whole tree structure of the program. But you are right, you need the full set of coordinates of a certain node's ancestors to properly know its coordinates, and having a line that begins with 1 or more spaces, it is impossible to deduce how many nodes deep it is without also having access to the previous line(s).
