Hi.
I've read the paper. From what I understood, the core idea is that source code maps to ast directly. Which is what lisp is already doing.
You say everything is a tree, but isn't this already so? Json, html, lisp, just to name a few languages. You call it 2D: an advancement in the y axis makes a "sibling" and in the x makes a "child". But children and siblings as a concept already exist, even though I haven't heard it called 2D programming yet.
Let's look at the example in the paper:
title Jack and Ada at BCHS
visitors
mozilla 802
This is basically a whitespace based syntax for lisp.
((title Jack and Ada at BCHS) (visitors (mozilla 802)))
So, I'm sorry, but I see no innovation in this new approach. Of course I could be wrong.
I'll comment your points in the paper:
1. ETN uses fewer nodes. Why? It maps to the same tree as the languages I already mentioned.
2. No parse errors. I have to say that I was writing in c++ recently, and the parsing wasn't an issue. And as you say, it doesn't make nonsense programs correct.
3. No semantic diffs. I didn't really understand, to be honest, but "just one way to encode a program" is wrong, imho. There are always many ways to the same thing. For example "a + b" is the same ad "b + a", and "a <= n" is the same as "a < n + 1" (when "a" and "n" are ints).
4. Easy composition. Python uses indentation, which collides with the syntax of TN. As long as you have reserved characters(and not having is probably impossible) you'll have to do something with languages that use them.
By the way, the whole idea seems to be that you can have nicer syntax, while I think the biggest advantage of writing ast directly is that you can create syntax. Obviously I could be wrong, I could have missed the point, it's perfectly possible.
Though it's hard once again to understand. When are two nodes coincident? By definition you can only have one character in one place on the screen. Is he talking about indentation, that the same level of indentation can mean different things? That seems true of ETN as well, from what I can tell.
The pencil scratchings on the screenshots don't help either.
Sorry, the lines in the geometric mapping of the source code are coincident. In drawing B) in the visual proof, the edges which connect the child nodes to their parents intersect and/or are coincident. So when you put Lisp source code onto graph paper, and draw boxes around the nodes, and line segments for edges, it shows why Lisp source is not a geometric language (I define a geometric language as one where there are no intersecting or coincident line segments).
Now, figure A) shows the same Lisp code, formatted differently, in a way that is a geometric language. But as you can see, that code is standard TN/ETN. Or perhaps another way to put it is ETNs are just Lisps with a whitespace syntax and no parentheses. Another reader on HN pointed me to I expressions (https://srfi.schemers.org/srfi-49/srfi-49.html), which I hadn't seen before and is 90% of the way there to TN and ETNs. The creator of I-Expressions have communicated briefly over email now and are going to be talking soon.
Anyway, perhaps another term for Tree Notation/ETNs is "Geometric Lisp", or "2-Dimensional Lisp". I'm not wedded to the terms TN/ETNs, although I do think it's better to have new terms, because I think these will come to dominate the usage of Lisp.
Still working on more updates and evidence on why I think these will be so big.
Thanks for the comments! The thing that z, readable, and wisp all lack, is that with ETNs every node has a point (x,y,z). So in addition to your source code mapping directly to your AST, it also maps to physical, geometric space (The Z axis is your program/document, the y axis is your line number, and the x axis is the column #/indent level).
So what you now have with ETNs, is the power of Lisp, now in a regular 2D/3D "structure", that you can inspect, visualize, and manipulate in new ways.
> 1. ETN uses fewer nodes. Why?
That's not compared to Lisps. Sorry, that was not clear. The paper was targeted toward a broader programming audience.
> 2. No parse errors. I have to say that I was writing in c++ recently, and the parsing wasn't an issue. And as you say, it doesn't make nonsense programs correct.
Ohayo briefly shows the power of no parse errors. Your program is parsed by little "micro-parsers", so there's no monolithic parse failure and programs can recover/autocorrect gracefully. More demonstrations here will do a better job of explaining. More to come.
> 3. No semantic diffs.
It's actually only "Semantic diffs" (not "not semantic diffs"). As opposed to syntax diffs. So "(+ 1 2)" and "(+ 1 2)" mean the same thing semantically in Clojure, for example, but git will give you a 1 line diff because of the whitespace syntax diff. In an ETN, "+ 1 2" and "+ 1 2" generally would be different, and could cause an ETN error unless the ETN allowed blank words.
4. Nothing collides. After years of going through every possible edge case, you cannot break TN. There is nothing that collides with the syntax. See for yourself. Download the library and create a TN with it's line/children set to something you think will collide. The indentation and ability to do "getTailWithChildren" takes care of all possible edge cases. (Sorry, I realize I still need to explain this better as this is a common concern and it is very surprising to people (myself included), that there are no edge cases that don't work.
