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

[Torben Hoffmann]

ok@REDACTED writes:

> I am viewing visual_erlang.pdf in Acrobat Professional
> and most of the figures are missing the connecting lines
> you'd expect to find in them.
>
That is most peculiar - I am using Skim, but opening in the free Adobe Reader shows
no signs of errors.

Are there any log files that states anything about my PDF being bad?

> This year I'm teaching part of a 4th year data base paper,
> where I'm talking about things like XML data bases and
> graph data bases, and part of a 4th year logic paper,
> where I'm talking about description logics (particularly
> EL and EL+), RDF, and OWL.  In past years I have been
> extremely frustrated by graphical tools that I could not
> *program*, where I *knew* there was information in the graph
> but I couldn't get it out.
>
> So for me one of the essential feature of any "boxes and
> connectors" notation is that there has to be a defined
> way to map that to some sort of set of facts that I can
> write queries on.  That is, it has to be more than pretty
> pictures.
>
> Turtle (RDF) is fine; SWI Prolog comes with a decent kit for
> loading/exporting/storing/querying RDF.  Datalog is fine too.
> It might be OK to make it something that can be visually
> manipulated in 'dia', and define a mapping between dia
> file format and a semantic form.
>
> Thing is, *IF* this (or any other notation) is any good at
> revealing just enough relevant structure, then it ought to
> be possible to write "flaw detectors" to spot antipatterns.
>
I'm certainly for this kind of formalism, but I am not able to do it since my
knowledge in this area is non-existent.

Do you have pointers to some introduction texts that can help guide the design of the
textual notation? And how to think about interrogating the information?

> It would also be interesting to have the connections between
> this notation and other notations like SDL or especially
> Maurice Castro's visual notation for Erlang.  (Anyone know
> what Maurice is up to these days?)
>
Thanks for the pointer on Maurice's notation - I had no idea about that one.
>From a brief read of it I think the main difference between that and Visual Erlang is
that in Visual Erlang the API functions are attached outside the module/process
instead of extending the rectangle for the process.



> My understanding is that in the early days of Erlang there
> was some pressure to tie it up with SDL, but it was found
> that there was a much clearer design notation for Erlang
> than SDL.  I believe it was called Erlang...
>
That is part of the reason why I have not just gone with SDL.

Another reason is that in SDL I am lacking a good way to capture links, monitors,
which is key to understanding how an Erlang architecture works.

SDL has an edge over Visual Erlang when it comes to capturing the flow of a protocol,
so either Visual Erlang has to focus on that as well or one simply uses SDL or MSCs
to capture that kind of information.

What I have been missing, and what drives me to create Visual Erlang, is a way to
capture how the supervision tree interacts with the functionality of the
module/processes.

Apart from being able to talk about what a process should be responsible for I am
also aiming at getting to a point where I can interactively browse through a code
base and uncover the architecture, while deciding which parts to hide through
abstractions. That is a bit down the road, though.

> Of course the present file is just a beginning, but there
> is a certain "flavour" that already has me wondering.
>
> When I read other people's Erlang code, I practically
> ALWAYS find myself desperately searching for certain
> information I regard as really important for my understanding.
> "Desperately" because the information is often missing.
> And this graphical notation currently has no place for it,
> and it's not even clear that a graphical notation is
> appropriate.  Yet it is something that Joe Armstrong has
> stressed the importance of, and built a toolkit to help in
> specifying and checking.
>
> It's the *PROTOCOLS* between the processes.
> By examining the source code of a module I can sometimes
> recover the protocol *as implemented*, but since people
> can make mistakes, that's not always the same thing as
> the protocol as *intended*.  In my own code, I tend to
> write the protocol down in comments, but *sigh* (hang
> head) don't always keep it up to date as the code changes.
> And of course the protocol-as-implemented in a receive
> loop can be the union of two or more protocols.  (For
> example, you might want a "management" protocol from a
> master to a worker but "clients" might be allowed to
> speak directly to the worker with a different protocol.)
> And of course part of a protocol might be implemented in
> a 'receive' and part of it in a 'case' somewhere else.
>
> *The* notation for specifying protocols has to be UBF
> (or some UBF variant).  How can that be integrated with
> a visual notation?

Funny that you bring this up - there has just been an application for an EU grant
(CoCo) to look at communication contracts between processes, which is very much about
building on top of UBF and get something that captures the protocols in the same way
specs capture types today.

I'd love to get protocols covered as well, but I don't feel that squeezing them into
Visual Erlang is the right approach.
I have stolen some of the ideas from Object-Process Methodology (OPM). In OPM there
is an explicit message flow semantics, but I do not find that particularly intuitive
when trying to understand the protocols.

As I said, SDL has more of the protocol stuff covered, but it is missing out on the
supervision tree. I think that protocols has to be addressed orthogonal to the
architecture captured in Visual Erlang. Preferably with some link between the two.
Hopefully the CoCo project will shed some light on this.

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