3 ms·

> (One reason we can't have good things in programming languages is that we're still using your father's parser generators.) I don't think it's the parsing tec

> (One reason we can't have good things in programming languages is that we're still using your father's parser generators.) I don't think it's the parsing technology that's the problem. It's that designing a good grammar is actually quite difficult. It's like doing UX design, API design, and mathematics all at the same time.

PaulHoule 5y ago
I'd respectfully disagree. Sometimes the grammar is already defined, already exists, and you just want to parse it. Sometimes you want to make a new grammar based on one that already exists, for instance: - add an "unless(X) {}" statement equivalent to "if(!X) {}" to Java - add a new SQL literal type to Java that compiles to something like JooQ; to make it easy lets use Unicode characters like « » to switch languages - almost any programming language contains an expression language that could be lifted out and used independently of the real language and slotted into another grammar (think making something like Python's list comprehensions, a business rules language, Microsoft's LINQ with SQL-like syntax) All of the above should be a few lines of code on top of existing grammars. Existing parser generators are one way: if they were two way (can unparse as well) you'd be in good shape for code generation. You should be able to write your grammar together with your AST objects easily (don't get me started about Yacc's callback hell interface.) The one feature I want from yacc is a PEG parser where it's as easy to set operator precedence as it was in the early C language parser. (Ought to be possible by rewriting the grammar... In fact there are a handful of problems with PEG parsers that everybody agrees should be fixable but nobody gets around to it.) ... and yeah, compiler books still say "Writing parsers that give comprehensible error messages is hard" without giving you any guidance as to how to do it.
- anthk 5y ago
  Text adventures are a different monster alltogether. And the i7 compiler it's almost a simple English parser by itself.

PaulHoule 5y ago

I'd respectfully disagree. Sometimes the grammar is already defined, already exists, and you just want to parse it. Sometimes you want to make a new grammar based on one that already exists, for instance: - add an "unless(X) {}" statement equivalent to "if(!X) {}" to Java - add a new SQL literal type to Java that compiles to something like JooQ; to make it easy lets use Unicode characters like « » to switch languages - almost any programming language contains an expression language that could be lifted out and used independently of the real language and slotted into another grammar (think making something like Python's list comprehensions, a business rules language, Microsoft's LINQ with SQL-like syntax) All of the above should be a few lines of code on top of existing grammars. Existing parser generators are one way: if they were two way (can unparse as well) you'd be in good shape for code generation. You should be able to write your grammar together with your AST objects easily (don't get me started about Yacc's callback hell interface.) The one feature I want from yacc is a PEG parser where it's as easy to set operator precedence as it was in the early C language parser. (Ought to be possible by rewriting the grammar... In fact there are a handful of problems with PEG parsers that everybody agrees should be fixable but nobody gets around to it.) ... and yeah, compiler books still say "Writing parsers that give comprehensible error messages is hard" without giving you any guidance as to how to do it.

anthk 5y ago
Text adventures are a different monster alltogether. And the i7 compiler it's almost a simple English parser by itself.