
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 11 Oct 2012, at 16:17, Rustom Mody wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">I have one more question that sits somewhere between parallelism and concurrency.<br>In the 'normal' world (ie C++, Java, Python) there is a general recommendation that converting a threaded solution to an event-driven solution usually speeds up the program and removes hard-to-find bugs.<br>And at the heart of an event-driven system is usually an FSM.<br>Now I am particularly interested in the combined (regular-exp+FSM) approach that ragel provides:<a href="http://www.complang.org/ragel/">http://www.complang.org/ragel/</a><br><br>In particular, here is the use of ragel to write an http server:<span class="Apple-converted-space"> </span><a href="http://www.zedshaw.com/essays/ragel_state_charts.html">http://www.zedshaw.com/essays/ragel_state_charts.html</a><br><br>Now since ragel is more or less language agnostic -- it has backends for generating C, C++, Java, Ruby etc -- would an Erlang backend for ragel make sense?</span></blockquote><br></div><div><br></div><div>As far as I can tell, Ragel is mainly for parser FSMs. As such, it seems</div><div>great, but I doubt whether it would add value to Erlang as a way to </div><div>specify concurrent (message-passing) state machines.</div><div><br></div><div>The thing it lacks that Erlang has, is selective message reception.</div><div>This allows Erlang to ignore a message in its inbox, and keep waiting</div><div>for the desired message. In coordination problems, this is a great </div><div>way to avoid complexity explosion.</div><div><br></div><div>I gave a talk about that a while ago:</div><div><br></div><div><a href="http://www.infoq.com/presentations/Death-by-Accidental-Complexity">http://www.infoq.com/presentations/Death-by-Accidental-Complexity</a></div><div><br></div><div>Basically, you _could_ generate Erlang FSM code from Ragel code,</div><div>I'm sure, but I think this would mainly be useful for porting existing</div><div>Ragel models over to Erlang. Ultimately, I think it would still be better</div><div>to do the 'porting' by hand, to give you a chance to think through the </div><div>problem in a more Erlang-ish style.</div><div><br></div><div>The FSMs that are easy to write in Ragel, also ought to be easy to</div><div>write in Erlang.</div><div><br></div><div>If I missed some clever device in Ragel that handles this, please </div><div>correct me.</div><div><br></div><div>BR,</div><div>Ulf W</div><br><div apple-content-edited="true">

<div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com">http://feuerlabs.com</a></div></div><div><br></div><br class="Apple-interchange-newline">

</div>

<br></body></html>