41–50 of 90 posts
Earlier quoted context omitted.
The only alternative is extracting them to other files or designing specialized string formats.
There is one obvious "specialized string format" that solves 99% of all escaping issues: use «balanced quotes». The real problem isn't escaping, it is that the same character is used both to open and close strings.
Earlier quoted context omitted.
The only alternative is extracting them to other files or designing specialized string formats.
There is one obvious "specialized string format" that solves 99% of all escaping issues: use «balanced quotes». The real problem isn't escaping, it is that the same character is used both to open and close strings.
There was an interesting discussion two years ago regarding nonobvious issues with PEGs: https://news.ycombinator.com/item?id=30414683 https://news.ycombinator.com/item?id=30414879 I spent a year or two working with PEGs, and ran into similar issues multiple times. Adding a new production could totally screw up seemingly unrelated parses that worked fine before. As the author points out, Earley parsing with some disa…
> Earley parsing with some disambiguation rules
Any idea why GLR always gets ignored?
Earlier quoted context omitted.
The only alternative is extracting them to other files or designing specialized string formats.
There is one obvious "specialized string format" that solves 99% of all escaping issues: use «balanced quotes». The real problem isn't escaping, it is that the same character is used both to open and close strings.
Earlier quoted context omitted.
The only alternative is extracting them to other files or designing specialized string formats.
There is one obvious "specialized string format" that solves 99% of all escaping issues: use «balanced quotes». The real problem isn't escaping, it is that the same character is used both to open and close strings.
Parsing computer languages is an entirely self-inflicted problem. You can easily design a language so it doesn't require any parsing techniques that were not known and practical in 1965, and it will greatly benefit the readability also.
Both GCC and LLVM implement recursive decent parsers for their C compilers.
Parser generators are an abomination inflicted upon us by academia, solving a non problem, and poorly.
Common example of complications of two grammars being combined: C code and character strings. Double quotes in C code mean begin and end of a string. But strings contain quotes too. And newlines. Etc. So we got the cumbersome invention of escape codes, and so characters strings in source (itself a character string) are not literally the strings they represent.
at no point in my life have I ever considered escape codes to be problematic. ugly, yes. problematic? no.
You can't always just copy and paste some text into code, without adding escape encodings.
Now write code that generates C code with strings, that generates C code with strings, and ... (ahem!)
It's not a big deal, but it isn't zero friction either. Relevant here because it might be the most prevalent example of what happens when even two simple grammars collide.
Have there been any notable innovations in parsing since this was written?
I'm not super familiar with the space, but tree-sitter seems to take an interesting approach in that they are an incremental parser. So instead of re-parsing the entire document on change, it only parses the affected text, thereby making it much more efficient for text editors. I don't know if that's specific to tree-sitter though, I'm sure there are other incremental parsers. I have to say that I've tried ANTLR and…
Also Tree Sitter only does half the parsing job - you get a tree on nodes, but you have to do your own parse of that tree to get useful structures out.
I prefer Chumsky or Nom which go all the way.
Parsing computer languages is an entirely self-inflicted problem. You can easily design a language so it doesn't require any parsing techniques that were not known and practical in 1965, and it will greatly benefit the readability also.
This is entirely the case. Given a sensible grammar stated in a sensible way, it's very easy to write a nice recursive decent parser. They are fast and easy to maintain. It doesn't limit the expressiveness of your grammar unduly. Both GCC and LLVM implement recursive decent parsers for their C compilers. Parser generators are an abomination inflicted upon us by academia, solving a non problem, and poorly.
A hand-written recursive descent parser (with an embedded Pratt parser to handle expressions/operators) solves all the problems that parser generators struggle with. The big/tricky "issue" mentioned in the article - composing or embedding one parser in another - is a complete non-issue with recursive-descent - it's just a function call. Other basic features of parsing: informative/useful error messages, recovery (i.e. don't just blow up with the first error), seamless integration with the rest of the host language, remain issues with all parser generators but are simply not issues with recursive descent.
And that's before you consider non-functional advantages of recursive-descent: debuggability, no change/additions to the build system, fewer/zero dependencies, no requirement to learn a complex DSL, etc.