It's been a while I've had to sit down applying or writing a parser or a parser generator, but it being/offering a "simple recursive descent" parser, does that mean left-recursion is a no-go?
In my opinion, parser libraries/frameworks indeed are all mired by the usual suspects which make adoption painful:
* Must learn another grammar language which for some strange reason I suspect has to do with "tradition", must reside in _a file_ -- as opposed to just be expressed with code (i.e. `bin_expr = Concatenation(Ref('expr'), bin_op, Ref('expr'))`); if a BNF language _is_ used for grammar, it almost always is used with some non-standard syntax for helping resolve shift/reduce errors, etc -- which for me puts it into the same "this is not needed" category
* Defined by the kind of parser that is generated, so implying you have to know parser theory in order to know what languages you will never be able to parse with said library/framework; made even worse when some kludge is added with extensive documentation on how to get out of the predicament because "the parser cannot theoretically handle the grammar/language but it otherwise is really great because it uses ABC kind of parsing which is why we chose it" -- the impression it gives a person who knows parsing enough to know they need to construct a grammar and that the grammar may feature ambiguities, is that they have to learn more parser theory; when you learn more parser theory, you usually just implement your own parser unless you need to parse e.g. C++, admittedly; for case in point, see my remark on the "recursive descent parser" being used with Lexy
To be frank, I like the addition of yet another parser generator -- the more the merrier, because contrary to that one earlier statement, that "parsing is a solved problem", I think it is not -- the theory has substantial headway on the practice, meaning that in theory it is [a solved problem], but in practice it is not, in my experience.
I assume yours is a general comment about parser generators and not specifically about Lexy, which in fact contradicts your first bullet point by providing templates to express your grammar directly in the C++ code.
The practice also lacks the answer to "when do you skip all the libraries and go for a hand rolled parser which gives you better control over errors, rollbacks, decision trees etc." step.
Neat. If you add some automatic memoization, I'll use it for my next project!
Here's the use case:
expr := ...
rule1 := expr foo expr
rule2 := expr bar
When trying to match rule1 and failing, it is great to have the expr part of it already parsed and ready for trying out rule2.
This doesn't have to be done extremely well (see PEG/Packrat parsing for that) but even a little bit, maybe one term or something like that helps a lot.
This appears to avoid one of the classic bugs with parser combinators (expensive backtracking and/or memory-use), but appears not to fix one of the other catastrophes.
To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"
>To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"
You're still not being explicit. Are you referring to the error recovery? Do you disagree that this is useful in real world applications? A C++ parser with `-Wall` would do error recovery and keep going on syntax errors.
It's been a while I've had to sit down applying or writing a parser or a parser generator, but it being/offering a "simple recursive descent" parser, does that mean left-recursion is a no-go?
In my opinion, parser libraries/frameworks indeed are all mired by the usual suspects which make adoption painful:
* Must learn another grammar language which for some strange reason I suspect has to do with "tradition", must reside in _a file_ -- as opposed to just be expressed with code (i.e. `bin_expr = Concatenation(Ref('expr'), bin_op, Ref('expr'))`); if a BNF language _is_ used for grammar, it almost always is used with some non-standard syntax for helping resolve shift/reduce errors, etc -- which for me puts it into the same "this is not needed" category
* Defined by the kind of parser that is generated, so implying you have to know parser theory in order to know what languages you will never be able to parse with said library/framework; made even worse when some kludge is added with extensive documentation on how to get out of the predicament because "the parser cannot theoretically handle the grammar/language but it otherwise is really great because it uses ABC kind of parsing which is why we chose it" -- the impression it gives a person who knows parsing enough to know they need to construct a grammar and that the grammar may feature ambiguities, is that they have to learn more parser theory; when you learn more parser theory, you usually just implement your own parser unless you need to parse e.g. C++, admittedly; for case in point, see my remark on the "recursive descent parser" being used with Lexy
To be frank, I like the addition of yet another parser generator -- the more the merrier, because contrary to that one earlier statement, that "parsing is a solved problem", I think it is not -- the theory has substantial headway on the practice, meaning that in theory it is [a solved problem], but in practice it is not, in my experience.
I assume yours is a general comment about parser generators and not specifically about Lexy, which in fact contradicts your first bullet point by providing templates to express your grammar directly in the C++ code.
Indeed, on the point of parser generators utilizing "text"-based grammar [files], Lexy is not among these.
The practice also lacks the answer to "when do you skip all the libraries and go for a hand rolled parser which gives you better control over errors, rollbacks, decision trees etc." step.
Neat. If you add some automatic memoization, I'll use it for my next project!
Here's the use case:
expr := ...
rule1 := expr foo expr
rule2 := expr bar
When trying to match rule1 and failing, it is great to have the expr part of it already parsed and ready for trying out rule2.
This doesn't have to be done extremely well (see PEG/Packrat parsing for that) but even a little bit, maybe one term or something like that helps a lot.
I parsed my language with it, it's fast and works well.
Pressing rules are written in c++ directly, with templates.
Although if you have no experience in parsing, the learning curve could be a bit steep.
This appears to avoid one of the classic bugs with parser combinators (expensive backtracking and/or memory-use), but appears not to fix one of the other catastrophes.
To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"
You have an odd notion of "explicit". There's no need to be coy ... spell it out.
[crickets]
>To be explicit: one of the "features" this advertises is equivalent to saying "if you stop compiling your code with `-Wall`, you don't have to deal with all those pesky warnings!"
You're still not being explicit. Are you referring to the error recovery? Do you disagree that this is useful in real world applications? A C++ parser with `-Wall` would do error recovery and keep going on syntax errors.
What “other catastrophes”? Are you being deliberately mysterious?