[ragel-users] Re: Question about nested state charts

[Adrian Thurston]

That define ... end define syntax comes from TXL. You're probably 
looking at cpp.grm, which is a TXL program that reads the output of 
cxxprep. The kelbt grammars are in .kl and .kh files.

TXL is pretty awesome, but it does have a dated syntax. My supervisor 
designed it and at that time keywordy syntax was hugely popular. Now ... 
not so much :)

I'm always interested in tough parsing problems to test Kelbt on. One 
thing to keep in mind is that it's research grade at the moment. In 
terms of usability it's going to be a little rough around the edges.

Adrian


Zed A. Shaw wrote:
> 
> On Thu, 21 Dec 2006 00:11:30 -0500
> Adrian Thurston <thurs... at cs.queensu.ca> wrote:
> 
>>
>> Hi Zed,
>>
>> I think nesting is a really good idea. Though Ragel can't build your 
>> machine exactly the way you've specified it. It's a limitation of the 
>> Ragel language and not of the underlying machines. When the end of a 
>> comma-separated list of machines is found Ragel tries to resolve all 
>> epsilon transitions inside it. So the epsilon drawn to Aborting is 
>> resolved when the inner join is complete, only the Aborting label 
>> doesn't exist at that time. What you want is for it to be resolved on 
>> the outer join but the language doesn't give you a way to say that.
> <snip>
> 
> Ok, this is possible since I can also set a state variable and then 
> alter the transition on final with an action.  There aren't a whole lot 
> of states right now by I like the idea of making is smaller.
> 
> One thing that I believe is *kind* of missing from the state chart idea 
> is "inheriting transitions".  I don't know if I like the idea, but when 
> I showed it to someone, they immediately thought that having a nested 
> chart be able to let a parent chart handle common events or transitions 
> would complete the state chart.
> 
>> About the duplication ... I've actually been meaning to add a feature 
>> for importing machine definitions. Though I wanted to wait until I 
>> finished rewriting the parsers before I start adding to them. I'm 
>> currently migrating to Ragel/Kelbt. In the meantime duplication is all 
>> there is ... which I'm aware is quite painful to many coders.
> 
> Oooh, kelbt looks interesting.  Downloaded it and will play with it.  My 
> favorite parser generator is Lemon, mostly because it has insane 
> debugging capabilities.  Please mimick Lemon this way :-)
> 
> One thing though, and more of a style choice, but I *hate* this syntax:
> 
> define conditionals
> ...
> end define
> 
> As you mentioned, I hate repetition, so making me type "define" twice is 
> really really annoying since your parser has got to be able to know that 
> "end" is enough.  Especially since it looks like you can't do nesting.  
> Even if you can, the end keyword should be enough to close off the 
> statement.
> 
> Anyway, i'll play with kelbt a bit.  If you're looking for a realworld 
> use on it, I know folks looking for powerful scaner/parser combos for 
> several open source projects.  I'll get them to try it out too.
>