Parsing: The Solved Problem That Isn't (2011)
1–10 of 71 posts
Re: Parsing: The Solved Problem That Isn't (2011)
#2I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way.
When you look at the simplicity of OMeta[1] you feel the difference. But I am not aware of any (production ready) OMeta implementation for C++.
Re: Parsing: The Solved Problem That Isn't (2011)
#3I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way. When you look at the…
If you don't mind incredibly long compile times for any moderately complex grammar, PEGTL is pretty straightforward compared to other alternatives.
Re: Parsing: The Solved Problem That Isn't (2011)
#4I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way. When you look at the…
The 'Accent' compiler-compiler can have some advantages over yacc.
Re: Parsing: The Solved Problem That Isn't (2011)
#5I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way. When you look at the…
The 'Accent' compiler-compiler can have some advantages over yacc. http://accent.compilertools.net
Thanks, I didn't have it on my list! I will try it.
Re: Parsing: The Solved Problem That Isn't (2011)
#6I just found this "old" article looking for an easy to use parser in C++ (in Visual Studio, GCC, and CLang). I think the current state of parsers in C++ is... how to say it... terrible! flex and bison doesn't look like C++, Boost Spirit too much ado, ANTLR4 doesn't support it yet and setting up ANTLR3 in Visual Studio can be explained in a few steps if it were explained in a straightforward way. When you look at the…
If you don't mind incredibly long compile times for any moderately complex grammar, PEGTL is pretty straightforward compared to other alternatives.
Re: Parsing: The Solved Problem That Isn't (2011)
#7My day job used to involve parsing some fairly ill-formed languages, so I developed this: https://github.com/Logicalshift/TameParse
I noticed with the languages I was working on, the problems could be resolved by being smarter with the lookahead: this parser allows for context-free lookahead matching to resolve (or detect and defer) ambiguities.
That makes it possible to do neat things like parse C snippets without full type information or deal with keywords that aren't always keywords (eg, await in C#).
Re: Parsing: The Solved Problem That Isn't (2011)
#8I've wondered why most existing LALR(1) parser generators are not replaced with LR parser generators with a higher look-ahead than 1. This improvement, considering that our computational power today does not justify these restrictions any more, would be Pareto-optimal even while it is being decided what completely alternative strategies (PEGs, boolean grammars, parser combinators, etc.) will take over.
Re: Parsing: The Solved Problem That Isn't (2011)
#9Jeffrey Kegler's work on Marpa is pretty exciting, but hasn't got much traction (maybe due to the implementation languages: Perl and Knuth's Literate Programming).
Re: Parsing: The Solved Problem That Isn't (2011)
#10I've wondered why most existing LALR(1) parser generators are not replaced with LR parser generators with a higher look-ahead than 1. This improvement, considering that our computational power today does not justify these restrictions any more, would be Pareto-optimal even while it is being decided what completely alternative strategies (PEGs, boolean grammars, parser combinators, etc.) will take over.
ANTLR is LL(*).