[erlang-questions] Visual Erlang notation v0.1.0 - feedback request

[Torben Hoffmann]

Vlad Dumitrescu writes:

> Hi,
>
> Just a thought that connects with the patterns discussion: linking to
> another process is usually permanent, that is we don't unlink from it.
> Process monitoring can be more dynamic. In any case, it is possible to have
> links/monitors that are dynamic and thus runtime properties. IMHO, one
> might want to handle these differently than the static ones. On the other
> hand, this might be an anti-pattern?
>
Ai, ai, ai!

Dynamic linking/monitoring is far from trivial.

The idiomatic danger of unlinking is that you can end up with processes that are no
longer associated with the supervision tree of your application.

In most cases you would probably have some naïve link in the supervision tree and
then add linking/monitoring from a different place in the tree to the processes you
are interested in.

Do you have a good example of where you use dynamic linking/monitoring that we could
base the discussion on?

I'd hate to provide notation for anti-patterns, but if we are missing something on
the dynamic front then now is a good time to get it in.

Cheers,
Torben




> regards,
> Vlad
>
>
>
> On Mon, May 5, 2014 at 10:59 AM, Torben Hoffmann <
> torben.hoffmann@REDACTED> wrote:
>
>>
>> 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.
>>
>> Cheers,
>> Torben
>>
>>
>> > /Erik
>> >  Den 02/05/2014 09.22 skrev "Torben Hoffmann" <
>> > torben.hoffmann@REDACTED>:
>> >
>> >> Hi,
>> >>
>> >> 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...
>> >>
>> >> https://github.com/esl/visual_erlang
>> >>
>> >> 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
>> >> architecture.
>> >>
>> >> Once I have updated the Erlang Concurrency Patterns that Jesper and I
>> have
>> >> been
>> >> 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
>> >> specific
>> >> 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.
>> >>
>> >> Cheers,
>> >> Torben
>> >> --
>> >> Torben Hoffmann
>> >> CTO
>> >> Erlang Solutions Ltd.
>> >> Tel: +45 25 14 05 38
>> >> http://www.erlang-solutions.com
>> >> _______________________________________________
>> >> erlang-questions mailing list
>> >> erlang-questions@REDACTED
>> >> http://erlang.org/mailman/listinfo/erlang-questions
>> >>
>>
>>
>> --
>> Torben Hoffmann
>> CTO
>> Erlang Solutions Ltd.
>> Tel: +45 25 14 05 38
>> http://www.erlang-solutions.com
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>


-- 
Torben Hoffmann
CTO
Erlang Solutions Ltd.
Tel: +45 25 14 05 38
http://www.erlang-solutions.com