[ragel-users] Re: for 6.0: going back to 3.X semantics for >, %, err

[Bruce Williams]

Adrian,

This sounds great; especially the '%' EOF action.

Cheers,
Bruce

---
Bruce Williams
http://codefluency.com

On 10/9/07, Erich Ocean <er... at atlasocean.com> wrote:
>
> That's great! +1 for the change.
>
> On Oct 9, 2007, at 3:48 PM, Adrian Thurston wrote:
>
> > Hi,
> >
> > In version 3 of Ragel the semantics of >, % and the error actions were
> > different.
> >
> > 1. The leaving operator '%' would also embed the action as an EOF
> > action
> > if the final states of the machine it was applied to remained final in
> > the compiled machine. This meant that as long as the machine didn't
> > error, the leaving action would always be executed even if it came
> > right
> > at the end of the input.
> >
> > 2. The starting transition operator '>' would embed a leaving action
> > into the start state if the start state was final. This meant that
> > if a
> > machine accepted the zero-length string and control passed through the
> > zero-length string then the starting transition action would still get
> > executed.
> >
> > 3. All global and local error actions would be executed when the input
> > ended in a non-final state (and the error action was embedded into
> > that
> > state).
> >
> > This semantics meant a single action block could be executed on a
> > regular character transition and on an EOF event. The problem was that
> > regular actions were generated in the main processing loop using
> > 'write
> > exec' and EOF actions were generated using 'write eof'. This often led
> > to compile errors because the context was not the same. You could fix
> > the compile errors by providing dummy variables to the EOF code, but
> > there would be no effect in the EOF code.
> >
> > This inconsistency seemed to drive up the complexity of these
> > operators
> > and in the 4.0 line I decided to simplify the operators by eliminating
> > the above action embedding behaviour.
> >
> > In the 6.0 release I will be bringing this behaviour back. Now that
> > EOF
> > actions are written in the main processing loop, they have
> > available to
> > them everything that regular actions have and the original problem
> > is gone.
> >
> > -Adrian
> >
>
>
> >
>