<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 31, 2014 at 12:47 AM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In other words, you want to define a contractual way that different processes<br>
can verify the external behavior of one another, instead of doing the actor<br>
version of duck typing that we tend to use all the time?<br></blockquote><div><br></div><div>It wouldn't be so much the processes verifying each other, but some overarching part of the runtime, or perhaps an analysis tool that verifies the "contract" for each process. Think of a type system: the type checker verifies that every function has the right type, and then a programmer who uses the function can be confident that the result of the function will be what they expect. I'm not saying I want to invent a type system, but I want to enable a similar style of reasoning for concurrent programs, where a programmer can just assume that another process acts in a certain way because that behavior is checked by another mechanism. Contracts in Racket (<a href="http://docs.racket-lang.org/guide/contracts.html">http://docs.racket-lang.org/guide/contracts.html</a>) also enable this kind of reasoning, although with enforcement happening at run-time.<br><br></div><div>I'm not sure what you mean by the "actor version" of duck typing, though. Could you expand on that, or point me towards an example?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If this is a runtime thing (and it would have to be in the case of empty<br>
processes which get assigned their behavior at runtime), then there would have<br>
to be a way to interrogate a process and ask it what messages it listens for<br>
and what the return type (if any) or side effects (if any) of receipt of those<br>
would be. Actually, it wouldn't be hard to write a framework or behavior that<br>
did exactly that. You would, as always, be depending on the programmer to not<br>
forget things and for processes to always tell the truth (consider the games<br>
we play with Dialyzer).<br></blockquote><div> <br></div></div>Again, I'm thinking of something closer to types or contracts where we don't assume the programmer always specifies the right behavior: any "wrong" behavior by the program would  (ideally) be detected and reported.<br><br></div><div class="gmail_extra">Really, though, I'm not sure exactly what kind of solution I'm targeting yet. I've observed that it's generally difficult to do the kind of reasoning I'd like to do in languages like Erlang, and I'm currently looking for concrete examples of this kind of problem. Then the plan is to study those examples, try to find a common pattern, and figure out what a useful solution would be. Without concrete examples, it's difficult to know if I'm solving the right problem.<br></div><div class="gmail_extra"><br>Regarding Dialyzer, I haven't actually used it myself, although I've read about it. Can you tell me more about what kinds of games you have to play with it?<br></div></div>