# Looking for feedback on my parser library

This topic is 4108 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I'm developing Parsnip, a packrat parser library for C++. Parsnip draws inspiration from parser combinator libraries like parsec. Parsnip freely intermixes lexing, parsing, and semantic actions. This overlap, in what are often separate realms, is well suited for prototyping and quick development. The Parsnip code is far from being stable or complete, but I've already been able to do some nifty things with remarkable ease. For an example of how Parsnip works, here is a parser which accepts key-value pairs in the format "key1 = value1; key2 = value2..." and returns an std::map of strings.
/*
the 'text' parser accepts any string of characters a-z and A-Z and returns that  string
*/
Parser<string, string>::type text = many(letters);

/*
1) the >> operator sequences two parsers
2) the skip function causes the result of a parser to be ignored
3) the token parser pads another parser in whitespace
4) the ch parser looks for its argument character in the input stream

All together the 'single_pair' parser takes pairs of the form sometext1 = sometext2 and returns a 2-tuple of strings
*/
Parser<string, Tuple2<string, string> >::type single_pair =
text >> skip(token(ch('='))) >>  text >> skip(ch(';'));

/*
'pair_parser' parses any number of 'single_pair's, passing the value
of each to a BuildMap<string, string> accumulator object. This accumulator
builds an std::map<string, string> from the tuples it receives.
*/
Parser<string, std::map<string, string> >::type pair_parser =
many< BuildMap<string, string> >(token(single_pair));


Since I'm still in an early stage of development, I'm not advertising Parsnip as ready for use. Rather, I'm looking for feedback, criticisms and requests. Thanks, Alex

##### Share on other sites
I mostly have two questions, that arise from my work with Boost.Spirit:

How does the user debug his parsers? Can one track the evaluation or have access to some other debugging tool?

How are errors handled? Can I get a position in the stream? Perhaps a 'line,column' kind of information?

##### Share on other sites
The debugging and error handling are embarrassingly primitive at the moment. Users can get the position at which parsing stopped...and that's it. Column counting can theoretically be implemented within the library (by attaching a semantic action to a newline parser), but I haven't written that yet. I'm planning on allowing the parsers to be tagged with names and error messages, but thus far it's just a thought. Debugging of the parser evaluation can be done by inspecting the call stack, though for complex grammars it can be rather confusing.

Does Boost.Spirit provide any special tools for debugging? What sort of error information does the user have access to?

##### Share on other sites
I read the documentation for Boost.Spirit's
error handling
and debugging . Both are remarkably sophisticated. I'm especially fond of the the tracing capabilities; if I had implemented something like BOOST_SPIRIT_DEBUG_RULE I would have saved myself a lot of time spent hunting problems.

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633710
• Total Posts
3013485
×