3 ms·

> 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

by 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.
- anamax 16y ago
  > 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. The existence of a parser does not imply its availability. As you said "Some of them don't have the parsers available at all (e.g. C)," > but some do (e.g. Python), Python does make a parse tree available, but not in a very useful fashion. You can use it to rewrite programs but not as part of ordinary programming. > In any case, your claim does not hold for "traditional languages" in any generality, there is too much variety. Actually it does because there are very few "traditional languages" that even approach Python's in-language support for their own AST, let alone come close to Lisp's. (Prolog and some of the logic programming languages have some AST support but I wouldn't call them "traditional". I don't remember if APL does.)
  - devinj 16y ago
    > The existence of a parser does not imply its availability. As you said "Some of them don't have the parsers available at all (e.g. C)," No, but it guarantees that, at least in theory, such a parser could be made available. In practice many languages do make it available. Your argument was a general one, that is that all "traditional languages" have this property. > Actually it does because there are very few "traditional languages" that even approach Python's in-language support for their own AST It only takes one counterexample to break a general claim. "Very few" is enough. Nothing about traditional languages has any intrinsic property of being parser and AST-free-- it is merely laziness, minimalism, or coincidence that causes many to not. As examples like Python show, it is quite easy to find a mainstream "traditional language" with a full-blown (actually several full-blown) interfaces to the parser available. Other languages have this too, although examples are not incredibly widespread. Lua has implementations which provide an AST, and even the hyper-traditional language C# has the Expressions framework, which lets you parse/modify/etc. the AST of an expression (including, of course, the new lambdas). It's just not true that Lisp is the only game in town for AST support, nor that "traditional languages" don't have it in general (although it may be true that most do not, this is not the same as claiming that as a group they do not).
jacquesm 16y ago
It's exactly the C programmers that care that use macros that will also use those extra parentheses. Especially when calling macros. Man you can be so badly bitten by bugs when your code expands to something almost identical, but not quite equal to working code. (free after Douglas Adams).

by anamax 16y ago

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.

anamax 16y ago
> 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. The existence of a parser does not imply its availability. As you said "Some of them don't have the parsers available at all (e.g. C)," > but some do (e.g. Python), Python does make a parse tree available, but not in a very useful fashion. You can use it to rewrite programs but not as part of ordinary programming. > In any case, your claim does not hold for "traditional languages" in any generality, there is too much variety. Actually it does because there are very few "traditional languages" that even approach Python's in-language support for their own AST, let alone come close to Lisp's. (Prolog and some of the logic programming languages have some AST support but I wouldn't call them "traditional". I don't remember if APL does.)
- devinj 16y ago
  > The existence of a parser does not imply its availability. As you said "Some of them don't have the parsers available at all (e.g. C)," No, but it guarantees that, at least in theory, such a parser could be made available. In practice many languages do make it available. Your argument was a general one, that is that all "traditional languages" have this property. > Actually it does because there are very few "traditional languages" that even approach Python's in-language support for their own AST It only takes one counterexample to break a general claim. "Very few" is enough. Nothing about traditional languages has any intrinsic property of being parser and AST-free-- it is merely laziness, minimalism, or coincidence that causes many to not. As examples like Python show, it is quite easy to find a mainstream "traditional language" with a full-blown (actually several full-blown) interfaces to the parser available. Other languages have this too, although examples are not incredibly widespread. Lua has implementations which provide an AST, and even the hyper-traditional language C# has the Expressions framework, which lets you parse/modify/etc. the AST of an expression (including, of course, the new lambdas). It's just not true that Lisp is the only game in town for AST support, nor that "traditional languages" don't have it in general (although it may be true that most do not, this is not the same as claiming that as a group they do not).

jacquesm 16y ago

It's exactly the C programmers that care that use macros that will also use those extra parentheses. Especially when calling macros. Man you can be so badly bitten by bugs when your code expands to something almost identical, but not quite equal to working code. (free after Douglas Adams).