Re^4: Parse grammar via RecDescent parser

That is an issue because I am calling 'eval' on the string returned. Also, this rule can only return the string as mentioned because it can be used in other rules doing && or ! or || operations on this. Therefore this rule can return only "-e <filename".

Comment on Re^4: Parse grammar via RecDescent parser

Replies are listed 'Best First'.
Re^5: Parse grammar via RecDescent parser by Corion (Patriarch) on May 17, 2016 at 14:39 UTC
Maybe you will need to adapt your logic then. If you want two things, but your other code can only handle a single thing, one or the other has to give. My first approach would be to only call `eval` on the first thing if an arrayref is returned. Other rules doing `&&` or `!` or `\|\|` on this result would not be affected by this, but they might also need to be adapted to cope with the result not being a single string. Let me note that you still have not shown us any workable example of what you have and what you want which is not amenable to a simple change like the one I outlined. My personal recommendation from having written half-assed parsers/program generators is to separate parsing the code from generating the output. Most approaches work on the resulting parse tree to restructure the tree according to simple rules and only after the (one or more pass off) restructuring generate the code from the tree.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Parse grammar via RecDescent parser
by Corion (Patriarch) on May 17, 2016 at 14:39 UTC

Maybe you will need to adapt your logic then.

If you want two things, but your other code can only handle a single thing, one or the other has to give.

My first approach would be to only call eval on the first thing if an arrayref is returned.

Other rules doing && or ! or || on this result would not be affected by this, but they might also need to be adapted to cope with the result not being a single string.

Let me note that you still have not shown us any workable example of what you have and what you want which is not amenable to a simple change like the one I outlined. My personal recommendation from having written half-assed parsers/program generators is to separate parsing the code from generating the output. Most approaches work on the resulting parse tree to restructure the tree according to simple rules and only after the (one or more pass off) restructuring generate the code from the tree.

[reply]
[d/l]
[select]