Hi all, This is a contrived example, but the solution should be the same. Assuming I have two rules, like so: section = identifier >> ch_p('{') >> *setting >> ch_p('}'); setting = identifier >> ch_p('=') >> value; // identifier and value are simple, but left off for brevity This should parse something like: somesettings { a = 12 b = "hello whirled" } Now, what I am looking to do is, if the parser fails parsing a value inside a "section", the parsing itself does not fail, but that section itself does. So if I also had: moresettings { this_is_valid = 12345 bigfaterror = 12"hi there"4.3"fewewfewfw" } Then the "somesettings" section would exist in the final AST, but "moresettings" would not. The error handling docs are a bit unclear to me, bit if I were to make a generic functor_parser which kept an error flag, how would I conditionally remove the section based on that value, seeing as it will already be mid-parse (I don't think something like if_p will work). Thanks in advance for any advice. On a side note, if I have a rule similar to (keyword >> identifier), the skip_parser will translate "somekeyword a" into "somekeyworda" and will parse it fine. However, what is to stop someone from removing the whitespace in the original code. With a quick glance, it appears the example c grammar from the spirit site will parse "voidfoo()" just fine due to this. Is there anyway I can tell the skip grammar to force a seperation? Thanks again, Aaron Griffin
Aaron Griffin wrote:
Hi all,
This is a contrived example, but the solution should be the same.
Assuming I have two rules, like so: section = identifier >> ch_p('{') >> *setting >> ch_p('}'); setting = identifier >> ch_p('=') >> value; // identifier and value are simple, but left off for brevity
This should parse something like: somesettings { a = 12 b = "hello whirled" }
Now, what I am looking to do is, if the parser fails parsing a value inside a "section", the parsing itself does not fail, but that section itself does. So if I also had: moresettings { this_is_valid = 12345 bigfaterror = 12"hi there"4.3"fewewfewfw" } Then the "somesettings" section would exist in the final AST, but "moresettings" would not. The error handling docs are a bit unclear to me, bit if I were to make a generic functor_parser which kept an error flag, how would I conditionally remove the section based on that value, seeing as it will already be mid-parse (I don't think something like if_p will work).
Just have a no_node parser after the failable bit: section = identifier >> ch_p('{') >> (*setting) | no_node_d[!ch_p('}')] >> ch_p('}'); (usual not-checked disclaimer) note that if you are careful, you could have the parser simply ignore the incorrect setting, or you could have an 'error node', or pretty much anything you can think of. This is if you want the error simply ignored: you may have to be a bit tricker otherwise.
Thanks in advance for any advice.
On a side note, if I have a rule similar to (keyword >> identifier), the skip_parser will translate "somekeyword a" into "somekeyworda" and will parse it fine. However, what is to stop someone from removing the whitespace in the original code. With a quick glance, it appears the example c grammar from the spirit site will parse "voidfoo()" just fine due to this. Is there anyway I can tell the skip grammar to force a seperation?
Most parsers where this matters that I've seen don't actually define a skip parser, they explicitly *space_p. Alternitively, parse a token stream, not a char stream. I leave this as an exersize for the reader ;-).
Aaron Griffin wrote:
Hi all,
On a side note, if I have a rule similar to (keyword >> identifier), the skip_parser will translate "somekeyword a" into "somekeyworda" and will parse it fine. However, what is to stop someone from removing the whitespace in the original code. With a quick glance, it appears the example c grammar from the spirit site will parse "voidfoo()" just fine due to this. Is there anyway I can tell the skip grammar to force a seperation?
The technique used in QuickBook is: keyword >> (eps_p - (alnum_p | '_')) ; // make sure we recognize whole words only (yes, the example C grammar should be fixed) Oh and BTW, the proper forum for Spirit is: spirit-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spirit-general Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 10/13/05, Simon Buchan
Aaron Griffin wrote:
...snip... Just have a no_node parser after the failable bit:
section = identifier >> ch_p('{') >> (*setting) | no_node_d[!ch_p('}')] >> ch_p('}');
(usual not-checked disclaimer) note that if you are careful, you could have the parser simply ignore the incorrect setting, or you could have an 'error node', or pretty much anything you can think of.
Thanks, that's exactly what I was looking for.
On a side note, if I have a rule similar to (keyword >> identifier), the skip_parser will translate "somekeyword a" into "somekeyworda" and will parse it fine. However, what is to stop someone from removing the whitespace in the original code. With a quick glance, it appears the example c grammar from the spirit site will parse "voidfoo()" just fine due to this. Is there anyway I can tell the skip grammar to force a seperation?
Most parsers where this matters that I've seen don't actually define a skip parser, they explicitly *space_p. Alternitively, parse a token stream, not a char stream. I leave this as an exersize for the reader ;-).
I was under the impression that using a skip parser did switch to a
token (phrase?) stream, using the skip parser as a token delimiter.
/me shrugs - Unless of course you're implying
The technique used in QuickBook is:
keyword >> (eps_p - (alnum_p | '_')) ; // make sure we recognize whole words only
(yes, the example C grammar should be fixed)
Going to try this, but I'm not sure if I fully understand. I just came across the distinct_parser family, so my question is: How is this different from using something like: distinct_parser_dynamic<> keyword_p(alnum_p | '_'); keyword_p("my_key_word") >> identifier;
Oh and BTW, the proper forum for Spirit is: spirit-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spirit-general
Done and done. Thanks. - Aaron Griffin
Aaron Griffin wrote:
Going to try this, but I'm not sure if I fully understand. I just came across the distinct_parser family, so my question is: How is this different from using something like: distinct_parser_dynamic<> keyword_p(alnum_p | '_'); keyword_p("my_key_word") >> identifier;
Same. Actually, the Quickbook technique prompted the distinct_parser thing. It's lighter, FWIW -- for the same reason why I prefer actual loops instead of the confix_p, list_p facilities. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
Aaron Griffin
-
Joel de Guzman
-
Simon Buchan