> You must be fucking with me by now. I'm honestly not. Also, let's try to keep this civilized. > and it's the parsing of said syntax that _results_ in trees.

> You must be fucking with me by now. I'm honestly not. Also, let's try to keep this civilized. > and it's the parsing of said syntax that _results_ in trees. When did I say otherwise? As you say, parsing concrete syntax indeed results in abstract syntax trees. Then those trees are used as input for semantic analysis (type checking, data flow analysis, etc.). Parsing is not semantic analysis. > Have you ever seen a tree in your syntax highlighting? The whole point to syntax highlighting, as well as good code formatting practices, is to make it easy to see the abstract syntax tree from the concrete program text. > Do you have a tree when you have a syntax error? If you're using a modern production compiler, yes. Compilers don't stop at the first syntax error. They add the error to a list, and then continue trying to build the syntax tree. > Syntax is independent and prior to your trees, I'd argue otherwise. When designing a programming language, abstract syntax comes first. You can define the semantics of a programming language purely in terms of its abstract syntax, and only later come up with a concrete syntax for it. > the IR in a compiler doesn't HAVE to use trees IR is what the compiler's frontend hands out to the backend. Syntax trees are an internal data structure used by the compiler's frontend.