[ragel-users] access prefix

ygrek ygrek at autistici.org
Tue Apr 26 20:41:18 UTC 2011

On Tue, 26 Apr 2011 08:05:40 -0700
Adrian Thurston <adrian.thurston at esentire.com> wrote:

> Ya that's a perfectly reasonable way to do it. I'd like to design ragel 
> for the most common case. I *think* making pe, pe and eof local is more 
> common, but I could be wrong.
> -Adrian
> On 11-04-25 09:02 PM, Brian Maher wrote:
> > [...]
> > Although Adrian is right about p, pe, and eof being rather
> > "transient", I find it easier to write functions that take a single
> > "struct" argument that manages the ragel state.  This way I can write
> > a function called state_machine that encapsulates all my actions for
> > the state machine, but ends up delegating each action to a function
> > that takes the "struct" as an argument.  I just find this way of
> > writing code is easier for me and my editor to digest.

Yes, this is exactly the reason for this question - I wanted to abstract over
ragel machine invocation so that it is more lightweight to use. Flexibility
is good and valuable, but the most popular case should be covered with least code.
My goal is somthing like this :

machive smth;
access state.;

module ParseSomething = struct
let init () =
  let state = Ragel.init () in
  %%write init;
let parse state data =
  %%write exec noprefix;
  Ragel.is_finished state

With the module Ragel being reusable (in different projects).
If p and pe variables are put in state then more common idioms can be reused, like

  >{Ragel.mark state} @{Ragel.extract state}


  module Ragel = struct
  let mark state = state.mark := state.p
  let extract state = String.sub data state.mark (state.p - state.mark)

When p and pe are kept local, all functions referencing them are also required to be local and
that means quite a bit of copypaste code.
So I think that having uniform way to gather all user-defined variables under single prefix
is worthwhile (maybe some modifier to %access or another keyword).


ragel-users mailing list
ragel-users at complang.org

More information about the ragel-users mailing list