Hi Erich,<br><br>I had not come across Harel's work before (believe it or not) so I read the paper containing the "spec" you mentioned. It was, needless to say, extremely interesting, and very relevant for the systems I design at work (which, I have only recently come to realize, are soft real-time systems). Having poked around in Ragel a little more I see that you are of course right when you say that it should complement rather than replace a hand-coded statechart.<br>
<br>Do you know of any examples of statecharts describing a protocol handler, or any good resources around statechart diagrams in general?<br><br>-Ross<br><br><br><div class="gmail_quote">On Tue, May 13, 2008 at 6:43 AM, Erich Ocean <<a href="mailto:er...@atlasocean.com">er...@atlasocean.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Ross,<br>
<br>
Statecharts are trivial to code by hand, using case and switch<br>
statements, and result in roughly the same amount of code as a<br>
straight Ragel implementation would. In addition, the hand-coded<br>
variants are more flexible, since you can implement the full "spec" as<br>
designed by Harel. You can also easily embed Ragel regex-style<br>
machines in the various states as needed when you hand code, and<br>
Adrian's code generation approach makes that particularly easy.<br>
<br>
Bottom-line: hand-code statecharts. The hard part is creating the<br>
statecharts themselves (I use OmniGraffle), not coding them up.<br>
<br>
That said, I wouldn't create a protocol handler without them. They are<br>
extraordinarily efficient, **easy** to debug, and quick to modify. I<br>
create and modify statechart-based code daily at my day job, and use<br>
statecharts on my own projects.<br>
<br>
Zed Shaw has done some work with Ragel and statecharts if you still<br>
want to go down that path:<br>
<br>
<a href="http://www.zedshaw.com/tips/ragel_state_charts.html" target="_blank">http://www.zedshaw.com/tips/ragel_state_charts.html</a><br>
<br>
Best, Erich<br>
<div><div></div><div class="Wj3C7c"><br>
On May 12, 2008, at 9:46 PM, Ross Thomas wrote:<br>
<br>
><br>
> It seems to me that the approach I describe cannot work as I wanted it<br>
> to, because the regexps matching the commands are duplicated for each<br>
> state, only with a different target state. For example:<br>
><br>
> main := (<br>
> start: (<br>
> 1 -> a<br>
> ),<br>
> a: (<br>
> 1 -> b<br>
> ),<br>
> ...<br>
> );<br>
><br>
> Given the input [1, 1] the machine will end up in state "a", not state<br>
> "final" as I thought. Which makes sense now I think about it.<br>
><br>
> Back to the drawing board... :)<br>
><br>
> -Ross<br>
><br>
><br>
> On Mon, May 12, 2008 at 6:15 PM, Adrian Thurston <<a href="mailto:thurs...@cs.queensu.ca">thurs...@cs.queensu.ca</a><br>
> > wrote:<br>
>> Hi Ross,<br>
>><br>
>> To be honest I don't have much experience with this approach.<br>
>> Statecharts were originally made for small low-level machines that<br>
>> are awkward to do with regular expressions. But they turned out to<br>
>> be more useful. The only issue I can think of is dealing with<br>
>> whitespace ... but I don't know SMTP well enough to say for sure.<br>
>> Let us know if if you pursue it and it works out :)<br>
>><br>
>> Adrian<br>
>> -----Original Message-----<br>
>> From: "Ross Thomas" <<a href="mailto:halfacan...@gmail.com">halfacan...@gmail.com</a>><br>
>><br>
>> Date: Mon, 12 May 2008 15:17:27<br>
>> To:ragel-users <<a href="mailto:ragel-users@googlegroups.com">ragel-users@googlegroups.com</a>><br>
>> Subject: [ragel-users] Re: Any suggestions on implementing SMTP<br>
>> protocol in<br>
>> Ragel?<br>
>><br>
>><br>
>><br>
>> To reduce the scope of my question a little, here is the general<br>
>> structure I have so far:<br>
>><br>
>> main := (<br>
>> start: (<br>
>> helo @copy_helo @resp_250 -> wait_mail |<br>
>> mail @resp_503 -> start |<br>
>> vrfy @resp_503 -> start |<br>
>> ...<br>
>> wait_mail: (<br>
>> helo @resp_250 -> wait_mail |<br>
>> mail @copy_mail @resp_250 -> wait_rcpt |<br>
>> vrfy @resp_252 -> wait_mail |<br>
>> ...<br>
>> );<br>
>><br>
>> Each "helo", "mail", "vrfy" etc. machine corresponds to the SMTP<br>
>> command of the same name. They are defined as:<br>
>><br>
>> helo = (("HELO"i | "EHLO"i) " " %sarg graph+ %earg eol);<br>
>> mail = ( "MAIL"i " FROM:<" %sarg path* %earg ">" eol);<br>
>> vrfy = ( "VRFY"i " " %sarg graph+ %earg eol);<br>
>> ...<br>
>><br>
>> So the idea is that the top-level state chart handles logical flow<br>
>> and<br>
>> knows which commands are valid in which states, and calls the<br>
>> appropriate actions. The tokenizing is done "inline", as it were.<br>
>><br>
>> Does this strike anyone as a particularly foolish approach? Is<br>
>> there a<br>
>> better way?<br>
>><br>
>> -Ross<br>
>><br>
>><br>
>> On Sun, May 11, 2008 at 11:57 AM, Ross Thomas<br>
>> <<a href="mailto:halfacan...@gmail.com">halfacan...@gmail.com</a>> wrote:<br>
>>><br>
>>> While hacking up a parser for SMTP (in an unprecedentedly small<br>
>>> amount<br>
>>> of time, naturally :)) it occurred to me that given Ragel's<br>
>>> ability to<br>
>>> mix regular expressions with state charts I could make the same<br>
>>> machine double-up as an SMTP protocol handler too. At least, I<br>
>>> think I<br>
>>> could. Because a significant portion of my work involves the client/<br>
>>> server model this is an aspect of Ragel I'd very much like to<br>
>>> explore<br>
>>> in more detail...<br>
>>><br>
>>> I've browsed around on the list and read Zed's post on state charts<br>
>>> but still don't have a totally clear idea on how this might be<br>
>>> implemented. Can anyone out there with more Ragel experience point<br>
>>> me<br>
>>> in the right direction?<br>
>>><br>
>>> -Ross<br>
>><br>
>><br>
>><br>
>><br>
>>><br>
>><br>
><br>
> ><br>
<br>
<br>
<br>
</div></div></blockquote></div><br>