3 ms·

>>If you write a code generator whose input is something like Forth ("operators are separated by spaces") you have written a compiler. Without a parser, how do

by rualca 5y ago

>>If you write a code generator whose input is something like Forth ("operators are separated by spaces") you have written a compiler. Without a parser, how do you expect to ingest those operators separated by spaces? Let alone verify that the input is valid? Either you are aware you are writing a parser, or you don't and end up doing very poorly. More importantly, the whole point of a compiler is not to output a binary. The whole point of a compiler is to allow developers to write code in a higher-level language that allows them to express programming constructs easily, and veridy and validate input to help pinpoint errors. Once you get to a AST then you can even say your work is already done.

kragen 5y ago
Yes, technically string.split() is a parser, but even in C it's two lines of code you really don't need a lot of parser theory to write: for (start = end; *start && isspace(*start); start++); for (end = start; *end && !isspace(*end); end++); I mean you can golf it a lot farther than that, but it's very little code even written perfectly straightforwardly like that without any tricks. One of the strong points of having your syntax be "operators are separated by spaces" is that it's impossible to have invalid input. You say, "The whole point of a compiler is to allow developers to write code in a higher-level language that allows them to express programming constructs easily, and verify and validate input to help pinpoint errors." Well, Forth is a higher-level language that allows you to express programming constructs easily, but it is not very good at verifying and validating the program to help pinpoint errors. However, I think most of the reason it's bad at validating is not because of its syntax (or lack thereof), but its semantic model: no types, everything is Turing-complete, referential opacity, etc. Forth's semantics opt for maximum flexibility at the cost of analytical tractability. I don't know about you, but I enjoy actually running my programs more than verifying and validating them, so I would not agree that your work is already done once you get to an AST. And I would say that a parser that produces an AST is not a compiler.

by rualca 5y ago

kragen 5y ago

Yes, technically string.split() is a parser, but even in C it's two lines of code you really don't need a lot of parser theory to write: for (start = end; *start && isspace(*start); start++); for (end = start; *end && !isspace(*end); end++); I mean you can golf it a lot farther than that, but it's very little code even written perfectly straightforwardly like that without any tricks. One of the strong points of having your syntax be "operators are separated by spaces" is that it's impossible to have invalid input. You say, "The whole point of a compiler is to allow developers to write code in a higher-level language that allows them to express programming constructs easily, and verify and validate input to help pinpoint errors." Well, Forth is a higher-level language that allows you to express programming constructs easily, but it is not very good at verifying and validating the program to help pinpoint errors. However, I think most of the reason it's bad at validating is not because of its syntax (or lack thereof), but its semantic model: no types, everything is Turing-complete, referential opacity, etc. Forth's semantics opt for maximum flexibility at the cost of analytical tractability. I don't know about you, but I enjoy actually running my programs more than verifying and validating them, so I would not agree that your work is already done once you get to an AST. And I would say that a parser that produces an AST is not a compiler.