[erlang-questions] Visual Erlang notation v0.1.0 - feedback request
Mon May 5 10:59:18 CEST 2014
Erik Søe Sørensen writes:
> It looks good - and appears to incorporate appropriate Erlang idioms.
> I will try it out at the next whiteboard design discussion :-)
Great - let me know how that works!
> There is one thing that bugs me, though: The representation of links as a
> dual monitor (or, equivalently, of monitors as one-way links).
> 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.
Thanks - that was the intention.
> But there are several differences between monitors and links:
> - the relation is asymmetric;
> - link behaviour is affected by trap_exit, monitor behaviour isn't;
> - links propagate exits, monitors don't;
> - reason 'normal' is special to links (when not trap_exit'ed).
> (And of course, the message format is different.)
You're right. I was unsure about how detailed this part should be, which was one of
my reasons for seeking feedback sooner rather than later.
> All in all, I believe we might be better off with a slightly different
> notation for monitors - say, a single-line-with-circle.
> Am I making sufficient sense?
You are making a lot of sense.
If I combine this with the request from Garrett, i.e., to make the notation more
Google presentation friendly we could do this:
* Use single line with open circle for monitors.
* Use single line with filled circle for links.
* Use single line with filled triangle style arrow head for spawn.
* Use dashed lines with open triangle style arrow head for message passing.
* Use dotted lines with open triangle style arrow head for exit signals.
Still not sure if we need a special notation for dealing with exit signals that are
being trapped. One could enforce that 'DOWN' has to be added to the message being
passed when a process is trapping exits.
Thoughts on all of this most welcome.
> Den 02/05/2014 09.22 skrev "Torben Hoffmann" <
>> As I have mentioned before I have been working on a visual notation for
>> Erlang and
>> although it is not complete yet I have received requests to release it
>> anyway, so
>> here goes...
>> One extra thing missing from the to-do list is state data for processes.
>> I would like some feedback on how you feel the abstraction level is.
>> The purpose of Visual Erlang is not to be able to specify every little
>> detail of what
>> happens in an Erlang program, but to give a way to describe the
>> Once I have updated the Erlang Concurrency Patterns that Jesper and I have
>> working on to the new Visual Erlang notation we will release them as well.
>> The original plan for the patterns was to use Object-Process Methodology
>> as the
>> notation, but I was adviced (and thanks for that) to invent an Erlang
>> notation since OPM has some corners that hurts for Erlang.
>> Right now the only way to draw Visual Erlang diagrams is by hand or use
>> the LaTeX
>> macros I have created, but since Visual Erlang has a 1:1 mapping between
>> the visuals
>> and a textual notation my hope is that we can create a tool that can
>> create a diagram
>> from the textual notation.
>> Going even further I dream of having a tool that extracts the Visual
>> Erlang notation
>> from the code in an interactive manner, where the user can guide what to
>> abstract and
>> what to just leave totally out.
>> Torben Hoffmann
>> Erlang Solutions Ltd.
>> Tel: +45 25 14 05 38
>> erlang-questions mailing list
Erlang Solutions Ltd.
Tel: +45 25 14 05 38
More information about the erlang-questions