5 ms·

...trees? Fair point, but we don't program with abstract syntax trees, unless we are talking about genetic programming.

by betenoire 11y ago

catnaroek 11y ago
Tell that to a compiler writer.
- betenoire 11y ago
  compiler writers write compilers in programming languages, not in syntax trees. Lisp is arguably the only language you write your code in "trees", but even then, it's still all lexical. A syntax tree is not syntax, it's a tree.
  - catnaroek 11y ago
    > it's still all lexical. I have no idea what you mean. Are you talking about lexical scope? If anything, determining the lexical scope of a variable is much easier from a syntax tree than from the original program text. > A syntax tree is not syntax, it's a tree. Pretty much all the literature on programming languages identifies “syntax” with “abstract syntax (tree)”. It is typically understood that textual concrete syntax exists primarily as a convenience for the programmer, because it's easier to edit, but the very first thing a compiler does is recover the abstract syntax tree, and from then onwards proceed as if the concrete syntax had never existed (except perhaps for error reporting purposes).
    - betenoire 11y ago
      Lexical means "as it appears 'written' on the 'page' of code". So lexical scope allows you to look and see what the binding is. Contrasted to dynamic scope where you must run the program to find the binding. If you will, syntax is the vocabulary of the language. Also called "lexicon" and the syntactical tokens are sometimes called "lexemes". It's all about the text. Syntax is text. Or more technically, syntax is the format of the input. Syntax trees are data structures that represent syntax, but they are not syntax. There are different types of syntax trees, too. The trees are built by the compiler, and never written by hand unless for exercise. Syntax trees have already passed semantic analysis and contain context. They are much more than just syntax.
      - catnaroek 11y ago
        > If you will, syntax is the vocabulary of the language. Also called "lexicon" and the syntactical tokens are sometimes called "lexemes". I'm pretty sure that most programming languages have their syntax defined in terms of two components: (0) a lexical specification [which lexemes are valid], (1) a grammar [how to arrange lexemes into well-formed programs]. And the latter tends to be richer and more complex than the former. So it isn't just, or even primarily about the individual lexemes. > It's all about the text. Syntax is text. Or more technically, syntax is the format of the input. Syntax is the (tree!) structure of utterings (declarations, statements, expressions, whatever). Textual representations of syntax just happen to be convenient to manipulate in a text editor. > Syntax trees have already passed semantic analysis and contain context. This is wrong. Syntax trees are the input for semantic analysis.
        betenoire 11y ago
        You must be fucking with me by now. Parsing IS context also, and it's the parsing of said syntax that _results_ in trees. That's why we have syntax highlighting. Have you ever seen a tree in your syntax highlighting? I didn't think so. Do you have a tree when you have a syntax error? No, because it never gets that far. Syntax is independent and prior to your trees, the IR in a compiler doesn't HAVE to use trees, it can use whatever it wants. I see there is no point in continuing this, we are arguing over definitions. Not even sure what we are talking about anymore.
        catnaroek 11y ago
        > 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.
TeMPOraL 11y ago
Or unless you're programming in Lisp. Lisp code is mostly its own AST.
groovy2shoes 11y ago
You didn't specify in your question that you only wanted to know what other kinds of syntax there are that people program in.

...trees? Fair point, but we don't program with abstract syntax trees, unless we are talking about genetic programming.

catnaroek 11y ago

Tell that to a compiler writer.

betenoire 11y ago
compiler writers write compilers in programming languages, not in syntax trees. Lisp is arguably the only language you write your code in "trees", but even then, it's still all lexical. A syntax tree is not syntax, it's a tree.
- catnaroek 11y ago
  > it's still all lexical. I have no idea what you mean. Are you talking about lexical scope? If anything, determining the lexical scope of a variable is much easier from a syntax tree than from the original program text. > A syntax tree is not syntax, it's a tree. Pretty much all the literature on programming languages identifies “syntax” with “abstract syntax (tree)”. It is typically understood that textual concrete syntax exists primarily as a convenience for the programmer, because it's easier to edit, but the very first thing a compiler does is recover the abstract syntax tree, and from then onwards proceed as if the concrete syntax had never existed (except perhaps for error reporting purposes).
  - betenoire 11y ago
    Lexical means "as it appears 'written' on the 'page' of code". So lexical scope allows you to look and see what the binding is. Contrasted to dynamic scope where you must run the program to find the binding. If you will, syntax is the vocabulary of the language. Also called "lexicon" and the syntactical tokens are sometimes called "lexemes". It's all about the text. Syntax is text. Or more technically, syntax is the format of the input. Syntax trees are data structures that represent syntax, but they are not syntax. There are different types of syntax trees, too. The trees are built by the compiler, and never written by hand unless for exercise. Syntax trees have already passed semantic analysis and contain context. They are much more than just syntax.
    - catnaroek 11y ago
      > If you will, syntax is the vocabulary of the language. Also called "lexicon" and the syntactical tokens are sometimes called "lexemes". I'm pretty sure that most programming languages have their syntax defined in terms of two components: (0) a lexical specification [which lexemes are valid], (1) a grammar [how to arrange lexemes into well-formed programs]. And the latter tends to be richer and more complex than the former. So it isn't just, or even primarily about the individual lexemes. > It's all about the text. Syntax is text. Or more technically, syntax is the format of the input. Syntax is the (tree!) structure of utterings (declarations, statements, expressions, whatever). Textual representations of syntax just happen to be convenient to manipulate in a text editor. > Syntax trees have already passed semantic analysis and contain context. This is wrong. Syntax trees are the input for semantic analysis.
      - betenoire 11y ago
        You must be fucking with me by now. Parsing IS context also, and it's the parsing of said syntax that _results_ in trees. That's why we have syntax highlighting. Have you ever seen a tree in your syntax highlighting? I didn't think so. Do you have a tree when you have a syntax error? No, because it never gets that far. Syntax is independent and prior to your trees, the IR in a compiler doesn't HAVE to use trees, it can use whatever it wants. I see there is no point in continuing this, we are arguing over definitions. Not even sure what we are talking about anymore.
        catnaroek 11y ago
        > 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.

TeMPOraL 11y ago

Or unless you're programming in Lisp. Lisp code is mostly its own AST.

groovy2shoes 11y ago

You didn't specify in your question that you only wanted to know what other kinds of syntax there are that people program in.