3 ms·

That Tree Notation? https://treenotation.org/ https://treenotation.org/ I don't get it. The descriptions are pretty wild and make little sense to me: > Tree N

by theamk 6y ago

That Tree Notation? https://treenotation.org/ https://treenotation.org/ I don't get it. The descriptions are pretty wild and make little sense to me: > Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing. But in practice, we have: - Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes. - Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output. - A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs? Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.

breck 6y ago
Your observations about the specifics are fairly good. The big idea is about dimensionality. All of the TIOBE languages are 1-dimensional. Parsed as a linear sequence of tokens, transformed to an AST, compiled. I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. Tree Notation is one very useful implementation of this bigger idea. In Tree Notation the shape of your source code is immutable during parsing. The AST and CST have the same shape. More abstract nodes stack up the z-axis like you would stack legos. Tree programs are isomorphic to geometric trees. Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning (as opposed to position in a linear sequence). Computers can to. And my bet is that they will https://longbets.org/793/ https://longbets.org/793/ It looks like a toy, but this will change everything. Or I could be wrong. https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkHk77nStQSGxgi https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...
- theamk 6y ago
  I still don't see what's different. > Parsed as a linear sequence of tokens, transformed to an AST, compiled. So are the Tree Notation programs. They are parsed as linear sequence of tokens -- when I look at the https://jtree.treenotation.org/designer/ https://jtree.treenotation.org/designer/ , the inputs are 1-d sequence of characters separated by spaces and newlines. Those are parsed one at a time, and make a tree structure. If the "2 dimensionality" refers to the fact that you have lines (Y dimension) and each line is split into words (X dimension), then this is not very new either -- this is how TCL and Unix shells view the world. > I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. I see no evidence of it. What can Tree Notation do that lisp/scheme can't? > In Tree Notation the shape of your source code is immutable during parsing. Are you talking about how characters on the screen correspond to nodes of your AST tree? If yes, than this seems extremely limiting. Each screen line is not that long -- probably 120 characters is a reasonable limit. What if you want a longer payload? What if in the output of your program has nodes with longer payload which no longer fit on the screen? Or is the idea that you take complex tree language, like s-expr, and _restrict_ it so it is representable as punctuation-free text? I guess this could be cool for education values, but I fail to see how such restrictions make the language "chasmically superior" > The AST and CST have the same shape. Like Lisp programs? > Tree programs are isomorphic to geometric trees. So are Lisp programs. > Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning Are you talking about character recognition or text parsing? The former is in parallel, but the latter is not. You can test it yourself trivially -- press the Zoom button in your browser. The font size changes, all the words move around, but you can still parse the text just fine. > Computers can to. And my bet is that they will. They already do! All the image recognition tasks (including character recognition) look at all the letters in parallel. You might have heard about this technology, it is called "neural networks". Moreover, they made special chips which work on a huge _2-dimensional_ matrix of numbers all at the same time! > but this will change everything. Or I could be wrong. I am not sure what is there to change, given that every part has been successfully used for many tens of years.
  - breck 6y ago
    > So are the Tree Notation programs. Today's machines impose a way of doing things. But in the future there will be a new type of machine. In the interim we can harvest a lot of benefits from Tree Languages by working within the constraints created by today's register model of computing. > on the screen The vast majority of research and experimentation with Tree Notation does not happen on the screen at all. Experiments are done in higher dimensions in different mediums. > So are Lisp programs. No they're not. There is a proof out there somewhere from 2017 proving why they are not. The 2-D layout is not an "afterthought". It is not a "beautified" version of Lisp. The 2-D layout is an essential ingredient of Tree Notation. You can change the rules of Lisp/SExp to achieve the same 2-D layout, and what you end up with is Tree Notation! So while Tree Notation can be thought of as one way to write S-Expressions, it's a very special way that has a 2-D geometric isomorphism that (this does not have). And that goes on to make a huge difference.

by theamk 6y ago

breck 6y ago

Your observations about the specifics are fairly good. The big idea is about dimensionality. All of the TIOBE languages are 1-dimensional. Parsed as a linear sequence of tokens, transformed to an AST, compiled. I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. Tree Notation is one very useful implementation of this bigger idea. In Tree Notation the shape of your source code is immutable during parsing. The AST and CST have the same shape. More abstract nodes stack up the z-axis like you would stack legos. Tree programs are isomorphic to geometric trees. Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning (as opposed to position in a linear sequence). Computers can to. And my bet is that they will https://longbets.org/793/ https://longbets.org/793/ It looks like a toy, but this will change everything. Or I could be wrong. https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkHk77nStQSGxgi https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...

theamk 6y ago
I still don't see what's different. > Parsed as a linear sequence of tokens, transformed to an AST, compiled. So are the Tree Notation programs. They are parsed as linear sequence of tokens -- when I look at the https://jtree.treenotation.org/designer/ https://jtree.treenotation.org/designer/ , the inputs are 1-d sequence of characters separated by spaces and newlines. Those are parsed one at a time, and make a tree structure. If the "2 dimensionality" refers to the fact that you have lines (Y dimension) and each line is split into words (X dimension), then this is not very new either -- this is how TCL and Unix shells view the world. > I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. I see no evidence of it. What can Tree Notation do that lisp/scheme can't? > In Tree Notation the shape of your source code is immutable during parsing. Are you talking about how characters on the screen correspond to nodes of your AST tree? If yes, than this seems extremely limiting. Each screen line is not that long -- probably 120 characters is a reasonable limit. What if you want a longer payload? What if in the output of your program has nodes with longer payload which no longer fit on the screen? Or is the idea that you take complex tree language, like s-expr, and _restrict_ it so it is representable as punctuation-free text? I guess this could be cool for education values, but I fail to see how such restrictions make the language "chasmically superior" > The AST and CST have the same shape. Like Lisp programs? > Tree programs are isomorphic to geometric trees. So are Lisp programs. > Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning Are you talking about character recognition or text parsing? The former is in parallel, but the latter is not. You can test it yourself trivially -- press the Zoom button in your browser. The font size changes, all the words move around, but you can still parse the text just fine. > Computers can to. And my bet is that they will. They already do! All the image recognition tasks (including character recognition) look at all the letters in parallel. You might have heard about this technology, it is called "neural networks". Moreover, they made special chips which work on a huge _2-dimensional_ matrix of numbers all at the same time! > but this will change everything. Or I could be wrong. I am not sure what is there to change, given that every part has been successfully used for many tens of years.
- breck 6y ago
  > So are the Tree Notation programs. Today's machines impose a way of doing things. But in the future there will be a new type of machine. In the interim we can harvest a lot of benefits from Tree Languages by working within the constraints created by today's register model of computing. > on the screen The vast majority of research and experimentation with Tree Notation does not happen on the screen at all. Experiments are done in higher dimensions in different mediums. > So are Lisp programs. No they're not. There is a proof out there somewhere from 2017 proving why they are not. The 2-D layout is not an "afterthought". It is not a "beautified" version of Lisp. The 2-D layout is an essential ingredient of Tree Notation. You can change the rules of Lisp/SExp to achieve the same 2-D layout, and what you end up with is Tree Notation! So while Tree Notation can be thought of as one way to write S-Expressions, it's a very special way that has a 2-D geometric isomorphism that (this does not have). And that goes on to make a huge difference.