Timeline for When to use a Parser Combinator? When to use a Parser Generator?
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 25, 2021 at 11:30 | history | edited | Kilian Foth | CC BY-SA 4.0 |
deleted 4 characters in body
|
| S Nov 10, 2019 at 11:21 | history | suggested | hippietrail | CC BY-SA 4.0 |
link first use of "DSL" for readers not familiar with the term; remove extraneous word
|
| Nov 9, 2019 at 3:54 | review | Suggested edits | |||
| S Nov 10, 2019 at 11:21 | |||||
| Sep 5, 2018 at 6:47 | history | protected | gnat | ||
| S Jan 2, 2017 at 0:44 | history | bounty ended | CommunityBot | ||
| S Jan 2, 2017 at 0:44 | history | notice removed | CommunityBot | ||
| Dec 30, 2016 at 9:13 | vote | accept | Qqwy | ||
| Dec 26, 2016 at 13:25 | answer | added | Qqwy | timeline score: 113 | |
| Dec 25, 2016 at 3:17 | answer | added | Mason Wheeler | timeline score: 8 | |
| Dec 25, 2016 at 1:14 | answer | added | Telastyn | timeline score: 5 | |
| S Dec 24, 2016 at 23:43 | history | bounty started | Qqwy | ||
| S Dec 24, 2016 at 23:43 | history | notice added | Qqwy | Canonical answer required | |
| Dec 23, 2016 at 17:20 | history | tweeted | twitter.com/StackSoftEng/status/812347222109155328 | ||
| Dec 22, 2016 at 23:42 | comment | added | Jörg W Mittag | … somehow a natural choice, but rather a constraint forced upon us by inferior tooling. Look at e.g. Perl6 or Fortress for some languages with powerful syntactic capabilities that cannot cleanly expressed in terms of lex/YACC derivatives. | |
| Dec 22, 2016 at 23:42 | comment | added | Jörg W Mittag | @Qqwy: Bryan Ford, who didn't invent but popularized PEGs and packrat parsers, argued that the reason why we see so many LR(1) languages is that we have so many LR(1) parsing frameworks and language designers subconsciously design LR(1) languages because they know that they will have to implement the language using an LR(1) parsing framework later. He suggested that if more powerful parsing frameworks became mainstream, language designers would design languages that look very different than today. In other words, his argument is that we see so many LR(1) languages today not because that is … | |
| Dec 22, 2016 at 23:38 | comment | added | Jörg W Mittag | @Qqwy: you mention ANTLR in your question. ANTLR not only stands for "ANother Tool for Language Recognition", it is also a pun on "Anti-LR", because the author believes that the overwhelming reliance on LR parser generators is wrong. ANTLR can parse any LL(k) grammar. In fact, it can parse any LL() grammar, and it is usually able to compute a pretty precise upper bound for k by itself, thus being able to generate an LL(k) parser for an LL() grammar. | |
| Dec 22, 2016 at 19:50 | comment | added | user188153 | Honestly, my compiler construction lecture is 30 years back (I wrote a Modula2 compiler that time). Most languages are LR(1), probably because a compiler is easier to write for that, LR(k), k>1 is less often. LL(k) even lesser, or other like LF and more strange variants (I only remember FORTRAN to be LALR(1)). | |
| Dec 22, 2016 at 19:27 | comment | added | Qqwy | @ThomasKilian the language I am thinking about right now uses almost completely postfix notation, which is indeed very compatible with BNF. I have to admit that no (context-free) language comes to mind that is based on a non-LR grammar. Could you give an example? | |
| Dec 22, 2016 at 19:21 | comment | added | user188153 | Your assumption above is based on BNF, which usually is simply compiled with lexer/LR parser combination. But languages are not necessarily based on LR grammars. So which is yours you are planing to compile? | |
| Dec 22, 2016 at 18:54 | comment | added | Qqwy | @ThomasKilian Interesting! Is there a distinction in the order of parsing between Parser Combinators and Parser Generators? (And parser interpreters?) | |
| Dec 22, 2016 at 16:59 | answer | added | Karl Bielefeldt | timeline score: 11 | |
| Dec 22, 2016 at 12:26 | comment | added | user188153 | I think it heavily depends on the language you are trying to compile. What type is it (LR, ...)? | |
| Dec 22, 2016 at 12:24 | comment | added | user188153 | @JörgWMittag Sounds more like an answer than a comment. | |
| Dec 22, 2016 at 12:20 | comment | added | Jörg W Mittag | … frameworks are not flexible enough to deal with that. Note also that there are parser frameworks that are not based on EBNF. E.g. packrat parsers for Parsing Expression Grammars. | |
| Dec 22, 2016 at 12:17 | comment | added | Jörg W Mittag | … has become a very high priority for language implementors). Also, many existing parser generators / interpreters / combinators are not really designed to cope with the great variety of demands that modern language implementations must fulfill. E.g. many modern language implementations use the same piece of code for batch compilation, IDE background compilation, syntax highlighting, automated refactoring, intelligent code completion, automatic documentation generation, automatic diagramming, etc. Scala even uses the compiler for runtime reflection and its macro system. Many existing parser … | |
| Dec 22, 2016 at 12:14 | comment | added | Jörg W Mittag |
There are at least two more ways of implementing parsers that you didn't mention: parser interpreters (similar to parser generators, except instead of compiling the parser language to e.g. C or Java, the parser language is executed directly), and simply writing the parser by hand. Writing the parser by hand is the preferred form of implementation for many modern production-ready industrial-strength language implementations (e.g. GCC, Clang, javac, Scala). It gives you the most control over the internal parser state, which helps with generating good error messages (which in recent years …
|
|
| Dec 22, 2016 at 11:44 | history | asked | Qqwy | CC BY-SA 3.0 |