> OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? Correct, not a goal of mine. If someone wanted to create a Tree Language

> OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? Correct, not a goal of mine. If someone wanted to create a Tree Language that compiles to CLisp, they could define it in our Grammar Language (http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/ -- you write your grammar on the left, and source code in your new language on the right). > So a list in treenotation would be written: list a 1 2 3 4 The base spec for Tree Notation is very simple. YI = "\n" // New lines separate nodes XI = " " // Increasing indent to denote parent/child relationship interface TreeNode { parent: &TreeNode children: TreeNode[] line: string } In practice, we generally break "line" into "words: string[]". So you can represent atoms in a list as either words or nodes, depending on how you design your Tree Language. > Could become a bit verbose at times, or does treenotation have a mechanism for tables like Sort of. We have a software coming out called TreeBase that is a plain text, git backed database that stores records in Tree Notation. In there we have Tree Languages for dealing with SSV/TSV/CSV/etc tables. I'm not 100% happy with the current implementation--going to be putting pattern matching into our Tree Grammar Language which might solve it--but I bet within a month or two we'll have a great solution for that with strong type checking, etc. > Does treenotation differentiate between strings and data/ints? The base Tree notation is very simple, as the spec above shows. But we created a Tree Language, built upon Tree Notation, wherein you write grammars to create new languages. In those grammar files you can define ints, strings, arrays, etc. The link above has examples with all of those.