3 ms·
He's not even right. He's pseudo rigorous to support is CL zealot trolling. He made it far enough into the wikipedia article to find a graphic that pseudo supp
by j-pb 8y ago
He's not even right. He's pseudo rigorous to support is CL zealot trolling.
He made it far enough into the wikipedia article to find a graphic that pseudo supports his claim, but not far enough to actually read the definition of an Abstract Syntax Tree (the thing we talk about) vs Concrete Syntax Tree (the thing he talks about).
> This distinguishes abstract syntax trees from concrete syntax trees, traditionally designated parse trees, which are typically built by a parser during the source code translation and compiling process.
- lispm 8y agoYou might want to reread the Wikipedia article and tone down a bit: Check out the abstract syntax tree on the right: https://en.wikipedia.org/wiki/Abstract_syntax_tree It has a node which is a BRANCH and which has three relations CONDITION, IF-BODY, ELSE-BODY. In an s-expression this is just (if (> a b) (setq a (- a b)) (setq b (- b a)) Thus there is no representation that IF is a branching expression, there is no representation that A and B are variables. There is no representation that > is a compare op. And so on. The s-expressions are just nested lists of tokens without any idea what the tokens refers to or what language construct it stands for. All we know is what the tokens are and a hierarchy. A is a symbol, but what kind we don't know: it could be a data object, a variable name, a function name, a goto tag, a name of a class, a name of a type, ...). In the abstract syntax tree the > is identified as a compare op, IF is identified as a branch, A is identified as a variable identifier, ... The Lisp reader also does not create that information. It just creates a data structure, which could be anything, any kind of data.