<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 29 Oct 2014, at 18:36, Jonathan Schuster <<a href="mailto:schuster@ccs.neu.edu">schuster@ccs.neu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">This morning I happened to find the "Erlang and Akka" thread from a couple of months ago, and it caught my eye because several people discussed exactly the sort of thing I'm researching right now: verifying that actor-based programs conform to some given protocol. In particular, I'm trying to figure out how we can do better for real-world programs instead of the simple examples used in things like session types.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div><div><br></div><div>I have used UBF, and like the idea of having a state- and type-based protocol checking. I thought a problem with UBF was that it really only dealt with synchronous protocols. I know Joe had some excellent ideas on how to move further, but I’m not sure they were ever implemented.</div><div><br></div><div>While type errors are certainly important, I believe unexpected message ordering is more so. I talked about that in my “Death by Accidental Complexity” [1] and got permission to publish the code used in the presentation [2].</div><div><br></div><div>Of course, any verification here would have to take into account that Erlang can implicitly ignore (buffer) messages in states where the focus is on only a few specific messages. Keeping track of message types, one could perhaps note if patterns are too general, so as to accept messages that are not expected to (or even must not) be handled in the current state. The POTS code mentioned above actually contains examples of that, where valid messages are discarded in states that do not recognize them, yet still consume them. This is in a way worse than crashing on a bad message, since this at least gives a fairly clear indication of what has gone wrong; instead the code ends up waiting indefinitely for a message that has already been received and discarded.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div>[1] <a href="http://www.infoq.com/presentations/Death-by-Accidental-Complexity">http://www.infoq.com/presentations/Death-by-Accidental-Complexity</a></div><div>[2] <a href="https://github.com/uwiger/pots">https://github.com/uwiger/pots</a></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><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></span><br class="Apple-interchange-newline">
</div>
<br></body></html>