[ragel-users] Some Ragel Ideas

[Adrian Thurston]

Hi Steve,

> Is this an appropriate place to discuss Kelbt?

Perhaps email is better for now.

> First off, could Ragel be extended to handle tail recursion? Direct
> tail recursion would be sufficient. Indirect tail recursion even
> better, but I imagine quite difficult.

In terms of just purely regular languages .. yes, I would think it would 
be doable. I imagine rewriting of the parse trees would be the proper 
way to do it. However, there might be issues with regards to the 
extensions to the regular language model. The user currently relies on 
the parse tree structure to reason about the order of execution of 
multiple actions on a single transition. Also, the parse tree is very 
important when reasoning about ambiguities. Parse tree rewrites might 
make reasoning about these things harder.

> Second, how about an equivalence assertion operator?

Ragel deals strictly with constructing deterministic state machines 
(that sometimes backtrack). There are many advantages to adhering to 
this model. Generating logic that executes a machine more than once on 
an input or that prints messages is outside of the scope of ragel.

On the other hand, at the machine construction level you could use the 
intersection operator & in Ragel to check if two machines match the same 
set of strings. For example, if two machines are identical then

( m1 | m2 ) - ( m1 & m2 )

should be empty (anyone please correct me if I'm wrong). A person well 
versed in language theory results (not me) would probably point you in 
the right direction.

> Third, Ragel seems to have a lot of cryptic operators. For those of us
> who will only be using it occasionally, it might be a bit more
> friendly if the less standard/obvious ones were given explicitly named
> equivalents. Perhaps something similar to...

Agreed. The operators are cryptic. Over the years I've played with 
various verbose embedding forms. So far nothing promising has been found 
so I've left it out of the docs. My current idea might be the one though.

main := m1 <-embedding_name(action_name)

or

main := m1 <-embedding_name{code}

This would also support user-defined embedding types, which I think is a 
big win.

Regards,
  Adrian