Re: [boost] [spirit] semantic action for mismatches?

Subject: Re: [boost] [spirit] semantic action for mismatches?
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-01-09 21:20:44

On 1/10/2011 9:58 AM, Eric Niebler wrote:
> On 1/9/2011 7:09 PM, Joel de Guzman wrote:
>> On 1/9/2011 12:36 AM, Eric Niebler wrote:
>>> On 1/7/2011 6:54 PM, caustik wrote:
>>>> I've come to notice that there seems to be a missing bit of
>>>> symmetry in spirit with regards to semantic actions.
>>>>
>>>> If a rule matches, and thus executes it's semantic action(s), but
>>>> a rule which includes that rule mismatches, there seems to be no
>>>> way to "unwind" the code executed down the chain. For example, if
>>>> one of your semantic actions allocates memory or increments a
>>>> reference count, how do you free / release that reference in the
>>>> mismatch scenario? I've thought about using something like a
>>>> shared_ptr, but it seems like that gets pretty sloppy and
>>>> unnatural. Is there something you can think of that would work?
>>>
>>> Just for reference, xpressive doesn't have this problem because
>>> actions are executed lazily. When a sub-pattern matches, its action
>>> is placed on a queue. If the pattern matching engine then needs to
>>> backtrack, the action is un-queued. Only when the *whole* pattern
>>> matches successfully is the entire action sequence executed ... in
>>> order, of course.
>>
>> We've considered that approach before, but what do you really mean
>> by sub-pattern?
>
> Anything that isn't the outermost pattern-match.
>
>> AFAICT, lazily evaluating actions can only be done
>> at the topmost (start) node since a sub-parser cannot really know
>> that it will be rolled back.
>
> Correct.
>
>> Alas, that approach does not work well
>> with fully typed attributed grammars and type-erased rules.
>
> I don't know about the "fully typed attributed" part, but type-erasure
> has nothing to do with it. Xpressive regexes are also type-erased. Only
> regex algorithms begin the pattern match. That entry point is what sets
> up the action context, and only the end state of the outermost regex
> causes the chain of actions to execute. Trust me, it works.

Of course I trust you! :-) But what works for xpressive might not
work with Spirit.

What is the signature of your lazy actions stored in the queue? How do
you make it accept and return arbitrary types (attributes)? Inherited
attributes may make use of continuation passing style but synthesized
attributes can't. That's what I meant. of course attributes do not
matter in xpressive.

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