On Wednesday, 29 February 2012 at 16:41:22 UTC, Andrei
Alexandrescu wrote:
On 2/28/12 7:16 PM, Christopher Bergqvist wrote:
What am I failing to pick up on?
Barrier of entry and granularity of approach, I think.
Currently if one wants to parse some simple grammar, there are
options such as (a) do it by hand, (b) use boost::spirit, or
(c) use lex/yacc.
Parsing by hand has the obvious disadvantages. Using
boost::spirit has a steep learning curve and tends to create
very contorted grammar representations, full of representation
noise, and scales very poorly. Using lex/yacc is hamfisted -
there's an additional build step, generated files to deal with,
and the related logistics, which make lex/yacc a viable choice
only for "big" grammars.
An efficient, integrated parser generator would lower the
barrier of entry dramatically - if we play our cards right,
even a sprintf specifier string could be parsed simpler and
faster using an embedded grammar, instead of painfully writing
the recognizer by hand. Parsing config files, XML, JSON, CSV,
various custom file formats and many others - all would all be
a few lines away. Ideally a user who has a basic understanding
of grammars should have an easier time using a small grammar to
parse simple custom formats, than writing the parsing code by
hand.
Andrei
Thanks for your response. The lowered barrier of entry in
parsing something like a customized JSON format or config files
is nice, and something I could see myself use. I'm still
skeptical about the level of "killer-featureness" but I would be
glad to be proven wrong.
