Every graph can be represented by a 2-dimensional tree.
Hence, every chart in this paper has a 2-D tree representation.
You can write that 2-D representation, and then without any type of transforming (keeping the shape of the graph in tree form untouched), you can turn it into a 3-D statechart, via the use of a Tree Language (https://jtree.treenotation.org/designer/)
So you get a 2-D text encoding of the statechart, editable in any dumb text editor or spreadsheet, isomorphic to the visual circles and lines diagrams they have, just as a 3-D rendering.
It's not that traditional a style as I had no experience in academia until after I published it on arxiv, but I still stand by basically all of it.
For the encoding all you need is 3 things: a node delimiter (generally newlines), a cell delimiter (generally tab or space), and an edge delimiter for parent/child relationships (generally reuse the tab or space from above).
Think of a spreadsheet as a program, and that's the base encoding.
From there you just need to define Grammars to get higher level constructs. This page (https://jtree.treenotation.org/designer/) contains ~15 example grammars, including a grammar for grammars (similar to YACC or ANTLR). This is just the tip of the iceberg though, you can do really novel things with these languages that you don't see with all our traditional languages (like having N parse heads that start all over the place and move in all sorts of directions).
So if you take these ideas and combine them with this "Statecharts" paper of 1987, what you would do is create a "Statecharts" Tree Language defining all the elements they have in that paper, and then people could write "programs" in this Tree Language, and then you could use the Compiler Compiler I linked to above to generate a compiler that reads those programs and either 1) compiles them to SVGs like they have in their paper or 2) generates 3-D visualizations where the program shape in the focus is unchanged.
ah sorry, i thought your OP was talking about a more graph-theory-ish thing, some fun bijection between trees and graphs or something, serialization isn't really what i had in mind
re: TN stuff. don't take this the wrong way, but being able to serialize a graph into bunch of IDs+edges isn't very... remarkable. as in, you could also use JSON/YAML/XML/s-exprs or whatever format, they'd be kind of equivalent here (modulo punctuation). i mean, lightweight DSLs and homoiconicity are cool, but not really groundbreaking stuff
---
PS (additional bit of unsolicited advice). afaik you're still looking for TN's "killer app"; i'd consider making something geared towards the org-mode/markdown/plain-text-everything crowd, because TN's advantage is conciseness + ease of input/editing + aesthetics. maybe it could find its niche as a markdown++/org-mode-ish thing where you can freely mix text with structured bits (DSL stuff would be handy here)
I hear what you are saying, but there is a big leap between TN and "JSON/YAML/XML/s-exprs". One is isomorphic to 2 and 3 dimensional structures, and the rest are not, connecting the software world to the physical world. This will turn out to be very important and groundbreaking.
> One is isomorphic to 2 and 3 dimensional structures, and the rest are not
So you're saying your notation can encode graphs that can't be represented as, e.g., JSON? The existence of such a graph would be the real (math-breaking) discovery here, no? I.e., you really should be able to give an example before offering such statements...
> connecting the software world to the physical world
The fundamental shape of all our current computer languages is one dimensional. You can take any current program/file, "encode it" to lego blocks, and it would be a one-dimensional string. This probably arises because our foundational layer is one dimensional binary.
Tree Notation/2D/3D languages are like a higher dimensional binary. Where you can traverse the program in multiple dimensions. Where physical layout matters.
Now all our current languages can be represented in this way. And that's what most of my stuff focuses on now.
But there are things that you can do with these languages and this style of 2D/3D architecture that you just cannot do with our current 1D register technology. (I mean maybe you could do them, but it would take billions of years to compute).
Wait, am I claiming that 2D/3D computers would be as big a development as Quantum computing?
No, much fucking bigger. Quantum computing is a fucking joke compared to this.
(pardon my french, I just find the occasional f-bomb as a good way to communicate my excitement about the OOM I am seeing)
not really sure what you mean by 2D/3D. if you mean "whitespace sensitive" (≈ effectively laid out in 2D), what about YAML? pretty sure you could just add dashes and get valid YAML representing the same tree:
- A
- B
- C
- A
to put it bluntly, i'm really not seeing what's so groundbreaking about using indentation to represent nesting – it's a nice concise syntax, but it's just that. if there's cool things you can do using that syntax (AIUI, Tree Languages and tools built around them, which reminds me of racket-lang and their whole "language-oriented programming" idea), that might be interesting; but failing that, people will dismiss your claims of being revolutionary as crankery, which will hurt your project's image.
Turn off the computer and "write" a program by assembling legos. One token is one lego block. So an open quotation mark—"—is one lego block. If you can align all the lego blocks in a single line, and the meaning of the program does not change, you have a 1-D programming language. This is the case for all the languages you mentioned—"JSON/YAML/XML/s-exprs".
This is not the case for Tree Notation/2-D and 3-D languages. Changing the 2-D positioning of the tokens changes the meaning.
Now you might say that this is not the case because you could just have a lego block that equals "\n", and so the parsing would be the same. But the mistake their is to miss the general idea of 2-D languages. While Tree Notation first parses a program linearly from start to end, that's just because it's a limitation based on how our current computers are designed to work, and having multiple read/execute heads starting and moving in different directions across a memory cube is not technology we currently have.
To put it another way: you don't need syntax characters, all you need is space.
> but failing that, people will dismiss your claims of being revolutionary as crankery, which will hurt your project's image.
I figured it would take ~10 years of hard work and dedication to chisel out the core of this idea and make it "just work" for people. I'm about 4 years in, so the bulk of the work and resources to put in are still ahead. I do not want to put so much effort and resources into a novel idea that wouldn't have much of an impact if it turns out to be correct. I give this idea a low probability of being groundbreaking (<10%), but if it is it will fundamentally change our languages and probably make a significant impact across society in many unpredictable ways (probably many orders small than binary notation, but many magnitudes bigger than most things). So I'm happy to sacrifice my "image" for this idea. I want people to be critical, especially now, still in the early days, to figure out the flaws here. I'm still not seeing one. From all the data I've seen so far, these types of languages will be a 10x+ leap in technology. It's a really big idea.
Hence, every chart in this paper has a 2-D tree representation.
You can write that 2-D representation, and then without any type of transforming (keeping the shape of the graph in tree form untouched), you can turn it into a 3-D statechart, via the use of a Tree Language (https://jtree.treenotation.org/designer/)
So you get a 2-D text encoding of the statechart, editable in any dumb text editor or spreadsheet, isomorphic to the visual circles and lines diagrams they have, just as a 3-D rendering.
You could probably put that in a paper.