Extracting detailed information from TypEr/Dialyzer

[Torben Hoffmann]

Hi again,

For one of my gen_fsm's I have been able to deal with {next_state, Var, ...}
by looking up the value of Var in the statements of the function clause -
not a full solution, but enough to cover my code.

Output example in CSP style:
CALL_BUSY_ORIGINATING =
  iz ? some_message
    -> qsig ! {cc_progress_request, isi_queuing}
    -> CALL_BUSY_ORIGINATING
  []
  iz ? another_message
    -> qsig ! {cc_progress_request, isi_connect_ack}
    -> CALL_ACTIVE_ORIGINATING_TX |~| CALL_ACTIVE_ORIGINATING_RX

This corresponds to two function clauses in the call_busy_originating/2
function where the clauses differ on what message their receive on their iz
interface. Then a message is sent on the qsig interface. The second clause
does some calculation to figure out what the next state should be, but at
this level I do not care about the details so I end the CSP clause with a
non-deterministic choice between the two states that can be the next state.

So now I have a nice compact overview of what my gen_fsm is doing which I
can use to communicate with non-Erlangers. The initial response was "This
looks fine!"... case closed.

But I would still like to get some insights on how TypEr/Dialyzer works
internally since I have a feeling that there must be code in there that can
be used to derive a more generic solution.

Cheers,
Torben

On Tue, Oct 12, 2010 at 09:00, Torben Hoffmann <torben.lehoff@REDACTED>wrote:

> Hi,
>
> I want to extract the following information from a gen_fsm:
>
>    - all the states
>    - the incoming events
>    - possible next states
>
> but I want to do it per function clause and not only on the function level
> as TypEr and Dialyzer does it.
> (I have to help a little by stating which functions are states in the
> gen_fsm, but that is so easy that I can live with the manual labour
> involved.)
>
> I have created a half-baked solution that is very specific to the code
> style I use so that I can extract the following about a gen_fsm:
> [{state_name(),{event(),
>                 [outgoing_messages()],
>                 {next_state,[state_name()]}]
>
> Each state has an entry in the list for each incoming event.
> (The format should probably be
> {state_name,event(),[outgoing_messages()],{next_state,[state_name()]}, but
> that is besides the point right now.)
>
> My problem is that my quick'n'dirty approach does not come out on top for
> all the next_state calculations since you can return from a function clause
> in many different ways.
>
> This kind of information must be available at some point during the TypEr
> and dialyzer processing of a file - I am okay with throwing my own code away
> if I get build on existing code and get the job done in a more general way
> than my current hack.
>
> Has anybody been down this road before me? If so, do you have some insights
> to share?
>
> For those who is questioning why I want to extract this information: I have
> modules which are several thousand lines long and no matter how readable and
> nice Erlang code is there is still a need to get a quick overview of what
> goes on in a module. The information above would be enough to create an SDL
> diagram of the main behaviour of a module which greatly helps when you have
> to communicate with non-Erlangers about the functionality of your code. This
> way I can acknowledge that the code is King and any manually created
> documentation is, well, at best a valiant Knight ;-)
>
> Thanks in advance,
> Torben
> --
> http://www.linkedin.com/in/torbenhoffmann
>



-- 
http://www.linkedin.com/in/torbenhoffmann