action ordering. is this a bug?

Steve Horne stephenhorne... at
Sun Feb 18 23:29:53 UTC 2007

I understand Adrian won't be around for a couple of weeks. I'm no
Ragel expert, but I'll make what I think is an educated guess and hope
someone sets both of us straight ;-)

> I would
> expect to see ">tbarz" first, but I don't.

>From what you are saying, I suspect you are confusing 'entering a
state' with 'entering a rule'.

Your 'tbarz' rule has a sequence of two instances of 'barz'. The first
'barz' will be recognised first. In a sense, this implies that the
recognition of the 'tbarz' rule has started - but the *state* where
'tbarz' has been fully recognised will not be entered until two
instances of 'barz' have been recognised.

Even entry actions aren't triggered at the start of a rule - they are
triggered on entry into the state where the rule has been fully
recognised. Basically, the recognition tends to find the smallest
building blocks first, progressing to larger building blocks later.

In general, entry actions *cannot* be triggered on (for instance) the
first character of a rule - you cannot know for sure which is the
right rule. Consider what happens when there are two alternatives, for

opt1 = a.b;
opt2 = a.c;
main = opt1 | opt2;

When the only input that has been examined is the 'a', you cannot tell
whether you have an opt1 or an opt2. Therefore you cannot choose the
correct entry action - this can only happen when you have also
examined the 'b' or 'c' and entered the state where either opt1 or
opt2 has been fully recognised.

> Is the behavior caused by the ambiguity of the grammar?

I don't think so. The finite state models generated by Ragel should be
fully deterministic unless the backtracking scanner syntax is used.
Ragel has disambiguating rules that it uses while compiling the state
model, using priority specifications and/or guarded operators, so you
will be getting the default (all priorities equal) disambiguations.

More information about the ragel-users mailing list