Every lambda calculus, including yours, corresponds to a Cartesian closed category. Your system is not at all as new as you think; what you are actually inventing are new ways to write down parsers, akin to the many other ways that folks are trying to write down programs in JSON or XML or YAML.
The only advantage that you've got at this point is a 2D addressing scheme, you might think, but E had that in the late 90s: http://www.erights.org/elang/kernel/LiteralExpr.html
Second time I heard this suggestion (https://news.ycombinator.com/item?id=20504193), thanks! Done. http://longbets.org/793/ - “In 2027, at least 7 out of the top 10 TIOBE languages will be Tree Languages AND/OR 0 out of the top 10 languages on 2017's list will be in the Top 10 in 2027. ”
> Your system is not at all as new as you think
I agree. It's mildly new. Tiny tiny little details that make a big difference in practice. To get here I had to stand on the shoulders of giants: built the largest DB of computer languages in the world (over 10k languages with over 1k columns).
> but E had that in the late 90s
Great reference, thanks. E and Kernel-E are great, but the devil is in the details. There are a tremendous amount of tiny little details in Tree Notation and Tree Language that compound to make this something new. You can't take anything out of Tree Notation without losing something important. Everything else you can add via a Tree Language. That makes this closer to binary, imo. There are at least a dozen things that could be taken out of Kernel-E, which itself is a subset of E.
Interesting question though. Can you elaborate?
How is this different than an Abstract Syntax Tree (AST)?
Each word has a location in 2D space. There is a physical manifestation of your program’s source code.
The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code.
So source == AST.
Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
<a><b></b></a>
===
<a>
<b>
</b>
</a>
How do you deal with large complex code? Lots of folding?
Large complex code hasn’t turned out to be too difficult yet. The key is well designed tree languages for the task at hand. Also, sublime text helps :). Have some code bases in the 6 digits loc. It’s all about tooling though. I don’t really use folding yet but perhaps that would be another feature that can make things easier, good suggestion. Things like type checking, syntax highlighting, auto complete, are essential.
In XML you would need to insert tags defining the whitespace so that it would be seen by programs operating on the AST.
Are your “two different structures” any different from the same representation in XML?
I think it’s a fair analogy to say tree Notation is just a much simpler XML.
At least 2x as simple:
<proof></proof>
proof
By 2020, we expect Flow to be a competitive rival to Python or R for 80% of data science tasks.
That's incredibly ambitious. Checking in -- are you within 4 months of reaching that goal?
I love this. So rare nowadays to scientists make bold predictions.
Disclosure: I work on Tree Notation (https://treenotation.org/).
Two years ago, in 2017 I predicted Tree Notation will be a silver bullet: by 2027 we will have a 10x improvement in reliability, productivity, and simplicity, thanks to the Tree Notation ecosystem.
2 years later, and thousands of experiments and conversations later, I'm almost positive that will happen.