<p dir="ltr">It looks good - and appears to incorporate appropriate Erlang idioms.<br>
I will try it out at the next whiteboard design discussion :-)</p>
<p dir="ltr">There is one thing that bugs me, though: The representation of links as a dual monitor (or, equivalently, of monitors as one-way links).<br>
The notation has the nice property that to see which other processes are affected when a given process dies, you simply look for circles around that process. That's good.<br>
But there are several differences between monitors and links:<br>
- the relation is asymmetric;<br>
- link behaviour is affected by trap_exit, monitor behaviour isn't;<br>
- links propagate exits, monitors don't;<br>
- reason 'normal' is special to links (when not trap_exit'ed).<br>
(And of course, the message format is different.)</p>
<p dir="ltr">All in all, I believe we might be better off with a slightly different notation for monitors - say, a single-line-with-circle.</p>
<p dir="ltr">Am I making sufficient sense?</p>
<p dir="ltr">/Erik<br>
</p>
<div class="gmail_quote">Den 02/05/2014 09.22 skrev "Torben Hoffmann" <<a href="mailto:torben.hoffmann@erlang-solutions.com">torben.hoffmann@erlang-solutions.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
As I have mentioned before I have been working on a visual notation for Erlang and<br>
although it is not complete yet I have received requests to release it anyway, so<br>
here goes...<br>
<br>
<a href="https://github.com/esl/visual_erlang" target="_blank">https://github.com/esl/visual_erlang</a><br>
<br>
One extra thing missing from the to-do list is state data for processes.<br>
<br>
I would like some feedback on how you feel the abstraction level is.<br>
The purpose of Visual Erlang is not to be able to specify every little detail of what<br>
happens in an Erlang program, but to give a way to describe the architecture.<br>
<br>
Once I have updated the Erlang Concurrency Patterns that Jesper and I have been<br>
working on to the new Visual Erlang notation we will release them as well.<br>
<br>
The original plan for the patterns was to use Object-Process Methodology as the<br>
notation, but I was adviced (and thanks for that) to invent an Erlang specific<br>
notation since OPM has some corners that hurts for Erlang.<br>
<br>
Right now the only way to draw Visual Erlang diagrams is by hand or use the LaTeX<br>
macros I have created, but since Visual Erlang has a 1:1 mapping between the visuals<br>
and a textual notation my hope is that we can create a tool that can create a diagram<br>
from the textual notation.<br>
<br>
Going even further I dream of having a tool that extracts the Visual Erlang notation<br>
from the code in an interactive manner, where the user can guide what to abstract and<br>
what to just leave totally out.<br>
<br>
Cheers,<br>
Torben<br>
--<br>
Torben Hoffmann<br>
CTO<br>
Erlang Solutions Ltd.<br>
Tel: <a href="tel:%2B45%2025%2014%2005%2038" value="+4525140538">+45 25 14 05 38</a><br>
<a href="http://www.erlang-solutions.com" target="_blank">http://www.erlang-solutions.com</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>