Scroll below for more information.
deck @termsurf/base
mark <0.0.1>
head <A TreeCode Package Manager>
term link-text
term computation
term philosophy
term information
term platform
term white-label
term compiler
face <Lance Pollard>, site <foo@bar.com>
task ./task
read ./note
lock apache-2
sort tool
link @termsurf/bolt, mark <0.x.x>
link @termsurf/nest, mark <0.x.x>
link @termsurf/crow, mark <0.x.x>These trees of terms are probably the simplest and easiest trees of text to read and write which you could conjure up. Frameworks can be built around the trees to process them, link them together into networks, and allow them to be used for optimized computation. The resulting runtime structures can be finely tuned infinitely from there, resulting in clean code, readable data, and fast programs. By convention we put them in .note files.
When taking notes in structured ways, TreeCode makes it practical and straightforward to quickly whip together intuitive Domain-Specific Languages (DSLs) of all shapes and kinds. It is also more powerful than pure JSON or YAML, because it can be thought of as code. It's all in how you leverage it to get the most power from it. It doesn't come with any bells and whistles, all of that can be found in tools built on top of this like StarNote.
Compare TreeCode to the standard data formats JSON/XML/YAML/etc. It's more difficult to get and stay in the zone while writing things down in JSON than it could be.
deck @termsurf/base
mark <0.0.1>
head <A TreeCode Package Manager>
term link-text
term computation
term philosophy
term information
term platform
term white-label
term compiler
face <Lance Pollard>, site <foo@bar.com>
task ./task
read ./note
lock apache-2
sort tool
link @termsurf/bolt, mark <0.x.x>
link @termsurf/nest, mark <0.x.x>
link @termsurf/crow, mark <0.x.x>{
"deck": {
"name": "@termsurf/base",
"mark": "0.0.1",
"head": "A TreeCode Package Manager",
"term": [
"link-text",
"computation",
"philosophy",
"information",
"platform",
"white-label",
"compiler"
],
"face": {
"name": "Lance Pollard",
"site": "foo@bar.com"
},
"task": "./task",
"read": "./note",
"lock": "apache-2",
"sort": "tool",
"link": [
{
"name": "@termsurf/bolt",
"mark": "0.x.x"
},
{
"name": "@termsurf/nest",
"mark": "0.x.x"
},
{
"name": "@termsurf/crow",
"mark": "0.x.x"
}
]
}
}However, it's not even accurate to render some of these as JSON or YAML, which are just keeping track of strings here. We can think of these as having imported values which are being bound to the tree structure. That is something a framework would tweeze out of your model and data definitions, using either a standard parser for common structures like functions and types, or you can make your own custom parser.
With TreeCode and TreeCode alone, you don't have much. Just as you don't have much with JSON by itself. You can use the TreeCode parser to get a tree structure which is defined in the spec. Then you transform the tree structure according to the rules you lay out for that tree DSL/pattern, and compile it into data, code, or both. Check out StarNote for the start on creating a coding/data framework on top of TreeCode. Still has a ways to go, but it will give you further ideas. And perhaps you can help us get it across the finish line!
Then, it's all about writing things down. First just go free form and write notes however you do, in Markdown, whatever. Then go back and find the data models in it, and create types, at least mentally. Then come up with the terms used to define the nests in the tree links, the anchor nodes so-to-speak, and then you are on your way to having a concise, clean way of capturing data of that form. That's the kind of thing we did to capture tons of vocabulary words into structured form, like these Cherokee words.
word <ᎠᎵᏍᏕᎸᏗ>
sense <Accommodate>
word <ᎠᎵᎪᏁᏗ>
sense <Accompany>
word <ᎠᏍᏆᏗᏍᏗ>
sense <Accomplish>We have the beginning outlines of tons of projects for collecting types and data on the GitHub org. Help make that happen, or start your own projects. The last step once you get your structured trees written down, is to parse and compile it, but that's where StarNote is headed.
These are all examples of terms and term trees.
xo
hello-world
foo-bar-baz
abc123
hello world
this is a tree
this
is
a
treeadd 1, 2
add 1, subtract -2, 3.14i #b0101, am bits
i #o123, am octal
i #xaaaaaa, am hexwrite <hello world>
text <
This is a long paragraph.
And this is another {type}.
>
moon <Cycles every {bold(<28 {period}s>)}.>These are common strings which don't need brackets.
load @some/path
load ./relative/path.png
load /an-absolute/other/path.js
load **/*.js
hook /@:user# comments are like ruby
# one per lineYes. TreeCode is usable today. The parser returns a detailed AST for the sytnax defined here, and from there you have to interpret the AST. See StarNote for an example of interpreting TreeCode.
Because TreeCode is the simplest possible way to write complex trees of data, simpler than JSON and YAML and XML. And because it is more robust, allowing for interpolation and interpretation. Finally, because it is easy for people to read and write, it lowers the barrier to entry, and potentially non-coders could contribute.
We are working on StarNote, a programming framework built on top of the TreeCode syntax. It will take a lot more work, if it's a solo developer then at least a year working ful time. With help, we can speed that up.
In short, you define a grammar using the mine DSL from StarNote, and then the compiler uses that grammar to compile your note tree to a structured object.