On 3/1/12 4:03 PM, Stephan Menzel wrote:
> On Thu, Mar 1, 2012 at 12:40 AM, Joel de Guzman
> <joel@...> wrote:
>> Ooops, sorry, that's wrong. Jeez, I need more coffee.
>> No it's not possible.
> Awww, man...
> And there was me, hopes a-rising.
> I have a very similar use case that I've been working on for days now.
> I need this in my DSL for 'if', 'or' and 'and' statements.
> Consider this:
> ifclause = lit("if")>> '('>> condition>> ','>> expression>>
> ','>> expression>> ')'
> ...where the first expression is to be executed if condition is true,
> otherwise the second.
> My DSL works in a way that it does the evaluation during parsing in
> phoenix semantic actions. Now if it's only about the return value,
> that is fine. But as soon as the expressions change the state of
> someting (like setting local variables or executing stuff) I'm in deep
> trouble. That is because both expressions are always parsed and
> therefore executed and since 'expression' can be many different things
> I have in this rule no way of finding out what actually happened
> Right now my phoenix actions are getting very compilicated because
> after long testing I came to the conclusion that the only way of doing
> this is to remember the state after 'condition' and then reset it
> after the first expression has parsed and condition returned false.
> Otherwise reset after the second expression to the state after the
> first. This may be OK for just one or two possible states but it's
> ugly and more like a hack than a solution. It would be cooler if in
> some way I could inhibit semantic actions for either the first or the
> second expression depending on the outcome of condition. Or switch
> parsers after condition to some without actions...
> Or am I missing an obvious solution here?
It is possible to implement what you guys want. "Classic" spirit actually
had a directive "no_actions_d" (IIRC the name), that does this.
Having said that, I would say that when you need such a thing, then
your semantic actions are getting too complex and you'd be better off
using ASTs-- which is the recommended Spirit-2 way of doing things.
Check out the compiler_tutorial, for example, where you can see
no semantic actions at all; just pure attributes and AST generation.
Doing it this way, you will be rewarded with grammars that are
declarative, very clear and concise without any imperative code.
At the most, you should be using semantic actions only to compose
your AST attributes for a rule.
ASTs are a joy to work with. You can traverse the AST post-parse
any way you want.
Joel de Guzman