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

[Vlad Dumitrescu]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140505/21e0641c/attachment.htm>