Think of your code in a spreadsheet or Cartesian plane.

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.

How is that different from XML?

In XML:

  <a><b></b></a>
  ===
  <a>
   <b>
   </b>
  </a>

In Tree Notation those are 2 different structures.

Interesting. Would you say this is similar to a visual programming language like Max/MSP? I was always intimidated by the large screens of spaghetti (almost literally, because of patch cords).

How do you deal with large complex code? Lots of folding?

Max MSP is definitely an inspiration of mine. Tree Notation is just a format, however. It could be an ideal way for a program like max to store its documents in, as opposed to an xml or a Json. It would allow dual visual / source editing. See our ohayo beta for an example. (note to self: add ohayo demo video)

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.

How are they different?

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?

This is a good point. When building a raw xml parser, these would be 2 different things.

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