4 ms·

> Come up with a better way of representing an Abstract Syntax Tree in text, please. If in programming what we're really doing is telling the compiler stuff, a

by devinj 16y ago

> Come up with a better way of representing an Abstract Syntax Tree in text, please. If in programming what we're really doing is telling the compiler stuff, and the compiler only sees an abstract syntax tree, traditional syntaxes are a way of representing an AST in text, and commonly considered to be "better" by the particular language's adherents (Ruby programmers like Ruby syntax, Java programmers like Java syntax, etc.). Sure, you don't get to apply proper macros, but Java/Ruby/etc. programmers don't care about that. What representation is "better" really boils down to taste and opinion.

DannoHung 16y ago
I think you're focusing on the wrong part of Abstract Syntax Tree. Lisp, fundamentally, has no syntax. It's just trees. That's the crux of how you write it. When fleitz said that he doesn't like the parens, I was just commenting, perhaps in too pithy a fashion, that the parentheses are incidental to the language. A vessel to hold the substance, as a glass holds water, if you will.
- deleted 16y ago
  [deleted]
- devinj 16y ago
  I see what you mean. But I don't think that's what he meant by Lisp. After all, if you believe that, then Python is a Lisp too[1]. And when people say "Lisp", they don't mean "Scheme and CL and [...] and Python". Sure, like any class of languages, there is not a single syntax. But every lisp has a syntax. And the languages people associate with the class "Lisp" use parens. And in many peoples' opinions, there are better ways of representing an AST. Like indentation, for example. Or curly brackets. 1: http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html
  - shaunxcode 16y ago
    Dylan is worth taking a look at to consider what lisp sans parens might look like. http://en.wikipedia.org/wiki/Dylan_%28programming_language%29 http://en.wikipedia.org/wiki/Dylan_%28programming_language%2...
  - DannoHung 16y ago
    You'll notice that in the first paragraph there, he says: > Python supports all of Lisp's essential features except macros, and you don't miss macros all that much because it does have eval, and operator overloading, and regular expression parsing, so some--but not all--of the use cases for macros are covered. Macros are a huge part of Lisp. Were they not, I don't think you'd see Lisp programmers defending the bare bones not-syntax so fiercely. For what it's worth, if you get good at a language, you start decomposing things into trees yourself when you're faced with some tricky code.
- demallien 16y ago
  Yes, exactly. The power of Lisp's 'syntax' is that anything expressible as an s-expr can be written in Lisp. This is not the case with other languages, even though they are all parsed into s-exprs. The parser simply can't produce certain s-exprs. *Actually, I'm not 100% sure that this is true - it would be more accurate to say that I am not aware of any other language that can be used to produce an arbitrary s-expr, but that such may indeed exist. If anyone can correct me on this point it would be much appreciated :-)
anamax 16y ago
> traditional syntaxes are a way of representing an AST in text, Actually, no. They're a way of unambiguously representing said AST. The just happen to be a lousy way of doing so. Let's see why. > and commonly considered to be "better" by the particular language's adherents Interestingly enough, almost none of those adherents actually know their favorite language's syntax. Why do I say that? Because very few people know the full precedence of expressions. So, they break expressions in unnecessary places and/or add redundant parentheses. And, the few folks who actually do know their language's syntax know better than to actually use that syntax because they know that the person reading their code doesn't know it, so they, the experts, are forced to over-parenthesize. > What representation is "better" really boils down to taste and opinion. And then there's the problem of manipulating said AST. To do so for a traditional language requires a parser and a bunch of datastructures, which every project reimplements. Everything that you need for lisp is built-in. And then there's the fact that Lisp's AST macro processing is built into the language processing scheme. > Sure, you don't get to apply proper macros, but Java/Ruby/etc. programmers don't care about that. The C programmers care, but they're used to being abused by C's macro system.
- devinj 16y ago
  > Actually, no. They're a way of unambiguously representing said AST. I'm not sure how that's a contradiction. "unambiguously representing" is still representing. > Why do I say that? Because very few people know the full precedence of expressions. So, they break expressions in unnecessary places and/or add redundant parentheses. Interesting, but not really relevant. They prefer the syntax, knowing that there are things they don't know about it. > And then there's the problem of manipulating said AST. To do so for a traditional language requires a parser and a bunch of datastructures, which every project reimplements. Everything that you need for lisp is built-in. Er, I don't understand how you can make that claim. A parser is necessarily built in to any interpreter/compiler for language with syntax, whether that language be a lisp or an assembly language or Java. Some of them don't have the parsers available at all (e.g. C), but some do (e.g. Python), and for some the parser is irrelevant (Lisps, machine code) because the AST (or "AST" perhaps, in the case of machine code) is always directly available regardless of explicitly calling out to the parser. In any case, your claim does not hold for "traditional languages" in any generality, there is too much variety.

by devinj 16y ago

DannoHung 16y ago

I think you're focusing on the wrong part of Abstract Syntax Tree. Lisp, fundamentally, has no syntax. It's just trees. That's the crux of how you write it. When fleitz said that he doesn't like the parens, I was just commenting, perhaps in too pithy a fashion, that the parentheses are incidental to the language. A vessel to hold the substance, as a glass holds water, if you will.

deleted 16y ago
[deleted]
devinj 16y ago
I see what you mean. But I don't think that's what he meant by Lisp. After all, if you believe that, then Python is a Lisp too[1]. And when people say "Lisp", they don't mean "Scheme and CL and [...] and Python". Sure, like any class of languages, there is not a single syntax. But every lisp has a syntax. And the languages people associate with the class "Lisp" use parens. And in many peoples' opinions, there are better ways of representing an AST. Like indentation, for example. Or curly brackets. 1: http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html
- shaunxcode 16y ago
  Dylan is worth taking a look at to consider what lisp sans parens might look like. http://en.wikipedia.org/wiki/Dylan_%28programming_language%29 http://en.wikipedia.org/wiki/Dylan_%28programming_language%2...
- DannoHung 16y ago
  You'll notice that in the first paragraph there, he says: > Python supports all of Lisp's essential features except macros, and you don't miss macros all that much because it does have eval, and operator overloading, and regular expression parsing, so some--but not all--of the use cases for macros are covered. Macros are a huge part of Lisp. Were they not, I don't think you'd see Lisp programmers defending the bare bones not-syntax so fiercely. For what it's worth, if you get good at a language, you start decomposing things into trees yourself when you're faced with some tricky code.
demallien 16y ago
Yes, exactly. The power of Lisp's 'syntax' is that anything expressible as an s-expr can be written in Lisp. This is not the case with other languages, even though they are all parsed into s-exprs. The parser simply can't produce certain s-exprs. *Actually, I'm not 100% sure that this is true - it would be more accurate to say that I am not aware of any other language that can be used to produce an arbitrary s-expr, but that such may indeed exist. If anyone can correct me on this point it would be much appreciated :-)

anamax 16y ago

> traditional syntaxes are a way of representing an AST in text, Actually, no. They're a way of unambiguously representing said AST. The just happen to be a lousy way of doing so. Let's see why. > and commonly considered to be "better" by the particular language's adherents Interestingly enough, almost none of those adherents actually know their favorite language's syntax. Why do I say that? Because very few people know the full precedence of expressions. So, they break expressions in unnecessary places and/or add redundant parentheses. And, the few folks who actually do know their language's syntax know better than to actually use that syntax because they know that the person reading their code doesn't know it, so they, the experts, are forced to over-parenthesize. > What representation is "better" really boils down to taste and opinion. And then there's the problem of manipulating said AST. To do so for a traditional language requires a parser and a bunch of datastructures, which every project reimplements. Everything that you need for lisp is built-in. And then there's the fact that Lisp's AST macro processing is built into the language processing scheme. > Sure, you don't get to apply proper macros, but Java/Ruby/etc. programmers don't care about that. The C programmers care, but they're used to being abused by C's macro system.

devinj 16y ago
> Actually, no. They're a way of unambiguously representing said AST. I'm not sure how that's a contradiction. "unambiguously representing" is still representing. > Why do I say that? Because very few people know the full precedence of expressions. So, they break expressions in unnecessary places and/or add redundant parentheses. Interesting, but not really relevant. They prefer the syntax, knowing that there are things they don't know about it. > And then there's the problem of manipulating said AST. To do so for a traditional language requires a parser and a bunch of datastructures, which every project reimplements. Everything that you need for lisp is built-in. Er, I don't understand how you can make that claim. A parser is necessarily built in to any interpreter/compiler for language with syntax, whether that language be a lisp or an assembly language or Java. Some of them don't have the parsers available at all (e.g. C), but some do (e.g. Python), and for some the parser is irrelevant (Lisps, machine code) because the AST (or "AST" perhaps, in the case of machine code) is always directly available regardless of explicitly calling out to the parser. In any case, your claim does not hold for "traditional languages" in any generality, there is too much variety.