Re: [Spirit-general] Attribute compatibility and Semantic actions

On 2/15/2011 10:36 PM, Hartmut Kaiser wrote:
>
>> Now, I committed code to the boost trunk that allows attribute
>> compatibility on semantic actions. This code (Boost trunk) will kick in
>> when you
>>
>>       #define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT
>>
>> This is necessary because the code is **will break existing code**.
>> Without the define, the old behavior will work as usual.
>>
>> So, what are the advantages:
>>
>> 1) The nice attribute compatibility rules can now apply to
>>      semantic actions giving us uniform behavior
>> 2) Parsers with semantic actions will now be a lot more
>>      efficient. While semantic-action-less attribute grammars
>>      are cool, a lot of times, we still have to resort to SAs
>>      to do some computation. This behavior will again give SAs
>>      equal footing in terms of performance.
>
> That's great! Although my guess is that it will not break too much of
> existing code. The change rather extends what's possible.

It will break code that uses both auto-rules and semantic actions
through the %= operator. Just for this case, the signatures of the
semantic actions will most likely have to change.

> Have you tried
> compiling the existing tests with this constant defined?

Not yet. I intend to do so.

> Now I need to implement something similar for Karma, I believe...

The code, in fact is deceptively simple: I just pass the
attribute parameter down to the parser and use that same
attribute to pass to the SA. This falls under the "why didn't
we think of that before" category; but... the caveat is that
on a failed match, the attribute is in an indeterminate state.
I am guessing that that is our current preferred behavior for
parsers anyway? --e.g. that's one reason why we have
the hold directive. Also, when you do something like:

     a >> b >> c

When c fails, the tuple attribute passed in already has
the attributes for a and b set. It would be wasteful if
we roll-back the tuple attribute to its original state.

So, with that in mind, I think the current behavior is
good. When we started Qi, we tried our best to restore
the attribute on a failed parse. I think now that this
should be clear for the sake of efficiency:

     On a failed match, the attribute is in an
     indeterminate state

This is contrary to the current docs has this as a
postcondition in Parser concepts:

     On a failed match, attrib is left untouched.

I do not think this is doable without incurring penalties in
efficiency. In fact, I think we are violating this anyway
with the sequence example (a >> b >> c) I presented above.

All that being said, I consider this as experimental. Let's
see how it goes.

I welcome everyone's comments and concerns.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com




------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb