Well, I've continued to think about this and I've got some more questions.
I did read up on the <defer: directive. I don't think that will help me. If
I'm missing something, please let me know.
So, I've come up with two different ways to handle this situation:
1. Pass in a boolean areguement to each production, and if that arguement
is "true" process the action, otherwise, simply return the TEXT of the
matched expression.
This way, my if statement passes [1] and [0] to the two clauses. This
introduces substantial logic into my grammar, though.
2. The other way is to build the "parse tree" inside the grammar and
then "walk" the tree. This would entail almost completely rewriting my
grammar actions. But this way would also, potentially?, allow me to compile
my language and forgo the parser step alltogether.
Which method would you recommend?
TIA,
Mike.
On Thursday 03 September 2009 15:25:29 Mike Diehl wrote:
> Hi all,
>
> I've got another problem and I'm hoping someone can point me in the right
> direction.
>
> My grammar is for a "language" that includes an "if" type command. The
> "if" command takes an expression, and two other commands. Depending on the
> values of the expression, ONE of the commands is supposed to be executed.
> However, what I'm seeing is that BOTH commands are being evaluated, but the
> results of only one of the commands is being used.
>
> Here is a snippet of the grammar:
>
> ===================================================================
> if: "[#if(" boolean_expression "," command "," command ")]"
> {
> if ($item[2] eq "true") {
> $return = $item[4];
> } else {
> $return = $item[6];
> }
> }
>
> command: variable | include | word | quoted_string
> {
> $return = $item[1];
> }
>
> include: "[#include(" file_path ")]"
> {
> $return = main::parse_page($item[2]);
> }
> ...
> ===================================================================
>
> So, in the case where we have a true expression, both commands are being
> evaluated, but only the results of one of the commands is returned. The
> problem is that, as in the case of an "include" command, the commands might
> have side-affects.
>
> I'm sure this is a common design pattern. Perhaps there is an "easy" way
> to deal with this?
--
Take care and have fun,
Mike Diehl.
