Best practices in gen_fsm usage

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Maxim Treskin-2
Hello

During years of work with Erlang/OTP I had many troubles with gen_fsm and
me not alone. A number of people who I know have the same troubles.
Here some of them:

1. gen_fsm incompatible with gen_server. We cannot use synchronous call
from gen_server for gen_fsm because it different.
2. Two different actions: send_event ? send_all_state_event with different
handlers. Why? If we want to send message to FSM, we just send message to
process without knowledge of its internal state-related issues, right?
3. For complex protocols and when one message emits almost equal actions in
various process states, code of gen_fsm-process becomes pumpkinized. Every
time I start writing a new gen_fsm module, I think that this time the code
will not become pumpkinized, but this wrong. Large number of pattern
matching with records in events and internal state of process in various
state handlers makes code duplicated and unreadable.

Is there any best practices in gen_fsm usage? May be I and other people
uses gen_fsm improperly?

Great Thanks

--
Maxim Treskin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/fea331df/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Thomas Lindgren-5
>________________________________

> From: Maxim Treskin <zerthurd>
...
>
>1. gen_fsm incompatible with gen_server. We cannot use synchronous call from gen_server for gen_fsm because it different.
>2. Two different actions: send_event ? send_all_state_event with different handlers. Why? If we want to send message to FSM, we just send message to process without knowledge of its internal state-related issues, right?
>3. For complex protocols and when one message emits almost equal actions in various process states, code of gen_fsm-process becomes pumpkinized.?Every time I start writing a new gen_fsm module, I think that this time the code will not become pumpkinized, but this wrong. Large number of pattern matching with records in events and internal state of process in various state handlers makes code duplicated and unreadable.
>
>
>Is there any best practices in gen_fsm usage? May be I and other people uses gen_fsm improperly?
>

Regarding points 1 and 2: My favorite approach to using gen_fsm, gen_server etc is to define all the calls to the server/fsm/... as an API, often in the server module itself. The client then just uses these API functions, while it's the job of the provider module to wrangle the raw gen_* calls.

Best,
Thomas


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Maxim Treskin-2
On 7 December 2011 14:49, Thomas Lindgren <thomasl_erlang> wrote:

> >________________________________
>
> > From: Maxim Treskin <zerthurd>
> ...
> >
> >1. gen_fsm incompatible with gen_server. We cannot use synchronous call
> from gen_server for gen_fsm because it different.
> >2. Two different actions: send_event ? send_all_state_event with
> different handlers. Why? If we want to send message to FSM, we just send
> message to process without knowledge of its internal state-related issues,
> right?
> >3. For complex protocols and when one message emits almost equal actions
> in various process states, code of gen_fsm-process becomes
> pumpkinized. Every time I start writing a new gen_fsm module, I think that
> this time the code will not become pumpkinized, but this wrong. Large
> number of pattern matching with records in events and internal state of
> process in various state handlers makes code duplicated and unreadable.
> >
> >
> >Is there any best practices in gen_fsm usage? May be I and other people
> uses gen_fsm improperly?
> >
>
> Regarding points 1 and 2: My favorite approach to using gen_fsm,
> gen_server etc is to define all the calls to the server/fsm/... as an API,
> often in the server module itself. The client then just uses these API
> functions, while it's the job of the provider module to wrangle the raw
> gen_* calls.
>
> Yes, this solution is acceptable, but it is yet another redundant layer of
abstraction.


> Best,
> Thomas
>



--
Maxim Treskin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/20e03d9d/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Vance Shipley-2
In reply to this post by Maxim Treskin-2
On Wed, Dec 07, 2011 at 01:31:42PM +0700, Maxim Treskin wrote:
}  1. gen_fsm incompatible with gen_server. We cannot use synchronous call
}  from gen_server for gen_fsm because it different.

Are you suggesting that you should be able to write:

     Reply = Module:call(Ref, Request)

Where Ref is a reference to either a gen_server a or gen_fsm?
You still need to use the correct module.  I don't see how much
that helps you over:

     Reply = case Module of
          gen_server ->
               gen_server:call(Ref, Request);
          gen_fsm ->
               gen_fsm:sync_send_event(Ref, Request)
     end

}  2. Two different actions: send_event ? send_all_state_event with different
}  handlers. Why? If we want to send message to FSM, we just send message to
}  process without knowledge of its internal state-related issues, right?

When you call gen_fsm:send_event/2 to send an event the function
StateName/2 in your callback module will be called for any state.
You don't need to use send_all_state_event/2 at all.  If you do
it is processed in your callback module's handle_event/3 function
and not the individual state's event handler StateName/2.

}  3. For complex protocols and when one message emits almost equal actions in
}  various process states, code of gen_fsm-process becomes pumpkinized. Every
}  time I start writing a new gen_fsm module, I think that this time the code
}  will not become pumpkinized, but this wrong. Large number of pattern
}  matching with records in events and internal state of process in various
}  state handlers makes code duplicated and unreadable.

How can it be any other way?  You say "_almost_ equal actions in
_various_ process states".  So it's not all states and not the same
action.  Therefore you need to uniquely handle events in states.

}  Is there any best practices in gen_fsm usage? May be I and other people
}  uses gen_fsm improperly?

Obviously putting common processing in seperate functions and calling
them from the state handlers is the way to handle 3.

If you still have a problem with 1 or 2 you might want to just simply
send messages ('Ref ! Request') and handle them in
gen_server:handle_info/2 and gen_fsm:handle_info/3.

If you are still unsatisfied you could implement your own FSM
behaviour in place of gen_fsm.  You may find this thread interesting:

        http://erlang.org/pipermail/erlang-questions/2005-April/015097.html

--
        -Vance



Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Max Lapshin
In reply to this post by Thomas Lindgren-5
On Wed, Dec 7, 2011 at 10:49 AM, Thomas Lindgren
<thomasl_erlang> wrote:
>>________________________________

> Regarding points 1 and 2: My favorite approach to using gen_fsm, gen_server etc is to define all the calls to the server/fsm/... as an API, often in the server module itself. The client then just uses these API functions, while it's the job of the provider module to wrangle the raw gen_* calls.
>


Your solution doesn't work in real life. I pass pid of process to the
handler, that makes gen_server calls (through some wrapper) and while
this process is gen_server, I get duck typing and everything works. If
process is gen_fsm, that this schema breaks and I need to pass
explicit type of this process: module where to call wrappers from.

Everything is going to be very complicated, but I refuse and delete
gen_fsm as useless code.


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Maxim Treskin-2
In reply to this post by Vance Shipley-2
On 7 December 2011 15:00, Vance Shipley <vances> wrote:

> On Wed, Dec 07, 2011 at 01:31:42PM +0700, Maxim Treskin wrote:
> }  1. gen_fsm incompatible with gen_server. We cannot use synchronous call
> }  from gen_server for gen_fsm because it different.
>
> Are you suggesting that you should be able to write:
>
>     Reply = Module:call(Ref, Request)
>
> Where Ref is a reference to either a gen_server a or gen_fsm?
> You still need to use the correct module.  I don't see how much
> that helps you over:
>
>     Reply = case Module of
>          gen_server ->
>               gen_server:call(Ref, Request);
>          gen_fsm ->
>               gen_fsm:sync_send_event(Ref, Request)
>     end
>
> So I need to pass behaviour with pid() of process to client.


> }  2. Two different actions: send_event ? send_all_state_event with
> different
> }  handlers. Why? If we want to send message to FSM, we just send message
> to
> }  process without knowledge of its internal state-related issues, right?
>
> When you call gen_fsm:send_event/2 to send an event the function
> StateName/2 in your callback module will be called for any state.
> You don't need to use send_all_state_event/2 at all.  If you do
> it is processed in your callback module's handle_event/3 function
> and not the individual state's event handler StateName/2.
>
> }  3. For complex protocols and when one message emits almost equal
> actions in
> }  various process states, code of gen_fsm-process becomes pumpkinized.
> Every
> }  time I start writing a new gen_fsm module, I think that this time the
> code
> }  will not become pumpkinized, but this wrong. Large number of pattern
> }  matching with records in events and internal state of process in various
> }  state handlers makes code duplicated and unreadable.
>
> How can it be any other way?  You say "_almost_ equal actions in
> _various_ process states".  So it's not all states and not the same
> action.  Therefore you need to uniquely handle events in states.
>
> Putting state name in #state{name = StateName} of gen_server gives
necessary result. We can do

handle_call(#request{... large pattern matching ...} = Request, From,
#state{name = StateName, ... another pattern matching...} = State) ->
  do_smth...,
  case StateName of
    %% State specific code
    ....
  end,
  do_yet_another_smth...,
  {reply, Result, State}

instead of copies `large pattern matching` Request with State if we use
gen_fsm.


> }  Is there any best practices in gen_fsm usage? May be I and other people
> }  uses gen_fsm improperly?
>
> Obviously putting common processing in seperate functions and calling
> them from the state handlers is the way to handle 3.
>
> If you still have a problem with 1 or 2 you might want to just simply
> send messages ('Ref ! Request') and handle them in
> gen_server:handle_info/2 and gen_fsm:handle_info/3.
>
> If you are still unsatisfied you could implement your own FSM
> behaviour in place of gen_fsm.  You may find this thread interesting:
>
>        http://erlang.org/pipermail/erlang-questions/2005-April/015097.html
>
> --
>        -Vance
>
>


--
Maxim Treskin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/53a85e25/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Vance Shipley-2
On Wed, Dec 07, 2011 at 03:13:59PM +0700, Maxim Treskin wrote:
}  So I need to pass behaviour with pid() of process to client.

Either that or use an accessor as Thomas described.

}  Putting state name in #state{name = StateName} of gen_server gives
}  necessary result.

Sure, go ahead and do that.  The gen_fsm behaviour is a tool to
help you implement communicating finite state machines which is
a common design pattern encountered in the real world.  If you
are working with FSMs but have no understanding of that you will
simply have a harder time conceptualizing the problem and it's
solutions.  On the other hand if you do understand the theory you
can then make an informed decision on an implementation.

The fact is that if you tried to implement an FSM decribed in 50
pages of SDL you'd get lost pretty soon using a gen_server.  Or
not ... it's just syntactic sugar.

--
        -Vance


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Max Lapshin
On Wed, Dec 7, 2011 at 12:27 PM, Vance Shipley <vances> wrote:
> Sure, go ahead and do that. ?The gen_fsm behaviour is a tool to
> help you implement communicating finite state machines which is

gen_fsm is not about finite state machines. Please, read definition of
this term before repeating these words.
It is mathematical term, that has some specific properties, that has
nothing to do with gen_fsm api.

> a common design pattern encountered in the real world. ?If you
> are working with FSMs but have no understanding of that you will
> simply have a harder time conceptualizing the problem and it's
> solutions. ?On the other hand if you do understand the theory you
> can then make an informed decision on an implementation.
>
> The fact is that if you tried to implement an FSM decribed in 50
> pages of SDL you'd get lost pretty soon using a gen_server. ?Or
> not ... it's just syntactic sugar.
>

It is exactly what Treskin was talking about. Show example of code,
which is better built on gen_fsm, than on gen_server.


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Ulf Wiger-5

On 7 Dec 2011, at 10:40, Max Lapshin wrote:

> On Wed, Dec 7, 2011 at 12:27 PM, Vance Shipley <vances> wrote:
>> Sure, go ahead and do that.  The gen_fsm behaviour is a tool to
>> help you implement communicating finite state machines which is
>
> gen_fsm is not about finite state machines. Please, read definition of
> this term before repeating these words.
> It is mathematical term, that has some specific properties, that has
> nothing to do with gen_fsm api.

This is a fairly narrow view. Finite State Machine is the commonly accepted name for the kind of model gen_fsm implements, and also what the 'fsm' part of the name stands for.

If you read the Wikipedia article on FSMs, you will find references to both UML and SDL state machines (http://en.wikipedia.org/wiki/Finite-state_machine#SDL_state_machines)

(SDL is now a subset of UML).

You can also read up on Finite State Machines in SDL here:
http://dtl.unimelb.edu.au/R/QQY97C1UTY254K3D1KPGXVP69M4V9G98R72NNCU48VJ54RDDDH-01973?func=dbin-jump-full&object_id=264093&local_base=GEN01&pds_handle=GUEST

(The examples described there can be mapped 1:1 to gen_fsm).

BR,
Ulf W


>
>> a common design pattern encountered in the real world.  If you
>> are working with FSMs but have no understanding of that you will
>> simply have a harder time conceptualizing the problem and it's
>> solutions.  On the other hand if you do understand the theory you
>> can then make an informed decision on an implementation.
>>
>> The fact is that if you tried to implement an FSM decribed in 50
>> pages of SDL you'd get lost pretty soon using a gen_server.  Or
>> not ... it's just syntactic sugar.
>>
>
> It is exactly what Treskin was talking about. Show example of code,
> which is better built on gen_fsm, than on gen_server.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions



Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Fred Hebert
In reply to this post by Max Lapshin
I submit to you my trade_fsm system as described in my Rage Against the
Finite-State Machines chapter (
http://learnyousomeerlang.com/finite-state-machines)

http://learnyousomeerlang.com/static/erlang/trade_fsm.erl

Another one would be a player process I've got for Process Quest:
http://learnyousomeerlang.com/static/erlang/processquest/apps/processquest-1.0.0/src/pq_player.erlthat
one is a bit weird because it's a standalone process that sends itself
the events it needs to move forward.

While there's no doubt it would be possible to do with a gen_server, I
doubt it would be much cleaner or easier to read or as self-descriptive
written that way. Using a gen_fsm makes it more obvious how the process is
supposed to behave, in my opinion.

On Wed, Dec 7, 2011 at 4:40 AM, Max Lapshin <max.lapshin> wrote:

>
>
> It is exactly what Treskin was talking about. Show example of code,
> which is better built on gen_fsm, than on gen_server.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/a58e5117/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Samuel Elliott
In reply to this post by Maxim Treskin-2
On Wed, Dec 7, 2011 at 7:56 AM, Maxim Treskin <zerthurd> wrote:

>
> On 7 December 2011 14:49, Thomas Lindgren <thomasl_erlang> wrote:
>>
>> >________________________________
>>
>> > From: Maxim Treskin <zerthurd>
>> ...
>> >
>> >1. gen_fsm incompatible with gen_server. We cannot use synchronous call
>> > from gen_server for gen_fsm because it different.
>> >2. Two different actions: send_event ? send_all_state_event with
>> > different handlers. Why? If we want to send message to FSM, we just send
>> > message to process without knowledge of its internal state-related issues,
>> > right?
>> >3. For complex protocols and when one message emits almost equal actions
>> > in various process states, code of gen_fsm-process becomes
>> > pumpkinized.?Every time I start writing a new gen_fsm module, I think that
>> > this time the code will not become pumpkinized, but this wrong. Large number
>> > of pattern matching with records in events and internal state of process in
>> > various state handlers makes code duplicated and unreadable.
>> >
>> >
>> >Is there any best practices in gen_fsm usage? May be I and other people
>> > uses gen_fsm improperly?
>> >
>>
>> Regarding points 1 and 2: My favorite approach to using gen_fsm,
>> gen_server etc is to define all the calls to the server/fsm/... as an API,
>> often in the server module itself. The client then just uses these API
>> functions, while it's the job of the provider module to wrangle the raw
>> gen_* calls.
>>
> Yes, this solution is acceptable, but it is yet another redundant layer of
> abstraction.

Just because we are functional programmers doesn't mean we should
throw away encapsulation. I *love* this method, because it completely
hides the fact I'm using gen_fsm - which after all is only an
implementation detail, and shouldn't matter more than that.
In fact in Hypernumbers, I think almost every single gen_server or
gen_fsm has an official API of functions that call into gen_*:call(),
but without ever invoking that directly. (Yes they do cope with the
fact that there might be multiple processes all using the same
callback modules).

Sam

>
>>
>> Best,
>> Thomas
>
>
>
>
> --
> Maxim Treskin
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>



--
Samuel Elliott
sam
http://lenary.co.uk/
+44 (0)7891 993 664


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Max Lapshin
In reply to this post by Max Lapshin
On Wed, Dec 7, 2011 at 6:50 PM, Adam Lindberg
<adam.lindberg> wrote:

>
> What exactly is the use case for being able to contact a process that implements either gen_server or gen_fsm via a standard API? I've never come across a use case where processes of different "types" needed to be mixed. If you really, really have to have that, you could implement a common interface via the handle_info/2 callbacks.

You haven't met. I have.

>
> - Either your process runs code that is based on gen_fsm, then you use a wrapper API that converts calls to corresponding gen_fsm calls (just as Thomas suggested).
>

What for?

I have never ever seen any _production_ code, which is better with
gen_fsm. Thanks to Fred for study examples, but they are study
examples.

Ulf told something about SDL, but I really don't know what is SDL.

I beleive that there may be situation, when gen_fsm is convenient. But
I ask only to show example of such code.


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Ulf Wiger-5

On 7 Dec 2011, at 18:04, Max Lapshin wrote:

> Ulf told something about SDL, but I really don't know what is SDL.

SDL = Specification and Description Language, is a ITU-T standard language for describing systems of communicating state machines. This was used much in Telecoms, and in real-time systems design, often together with Message Sequence Charts (MSC), to produce high-level systems architecture diagrams.

SDL also extends down into programming with SDL/PR, but we can ignore that. ASN.1 - a loosely related data description layer - is however still quite relevant.

In the great UML:ification, SDL was absorbed into UML. Before that, it became more and more object-oriented. Still, the earlier versions are actually fairly decent for describing erlang-based systems. In fact, it was once shown that a system described in SDL could be mapped 1:1 over to Erlang. This has not been done much, since it was also easy to demonstrate that the same system could be more easily described in Erlang in the first place (although such a description would lose many of the qualities of a good system architecture description).

Here is a tutorial of sdl88. The link jumps directly into something that ought to look familiar:

http://www.sdl-forum.org/sdl88tutorial/4.ProcessCommunication/4.1_Signal_input_queue.htm

Here's another overview:
http://www.cs.nthu.edu.tw/~tanghome/SDTDoc/introsdl.html

BR,
Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/217aa3f3/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Fred Hebert
In reply to this post by Max Lapshin
On Wed, Dec 7, 2011 at 12:04 PM, Max Lapshin <max.lapshin> wrote:

>
> I have never ever seen any _production_ code, which is better with
> gen_fsm. Thanks to Fred for study examples, but they are study
> examples.
>
> I beleive that there may be situation, when gen_fsm is convenient. But
> I ask only to show example of such code.
>
>
Fortunately this isn't a hockey game, because the moving goal posts would
make it quite hard to score a goal ;)

If I make a website using my code and then make it public, does it become
production code? Are there other hidden criteria?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/c908be0b/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Torben Hoffmann-3
In reply to this post by Ulf Wiger-5
Adding to the SDL wagon: I have had to implement the Q.SIG standard and
with a little thought it is possible to get Erlang code that is almost
1:1 with the SDL diagrams - there is a little example in the EUC 2010
presentation by Raghav Karol and me where we have one function call for
each box in the SDL diagrams. That makes it very easy to debug the code
in the rare case that one has done something wrong ;-)

But for creation of new software where there is no SDL specification of
the protocols there is no real benefits of creating SDL before coding.
For that I think that Object Process Methodology (used lightly) and
Message Sequence Charts are better ways of structuring your high level
thoughts.

Cheers,
Torben

On 7/12/11 18:24 , Ulf Wiger wrote:

>
> On 7 Dec 2011, at 18:04, Max Lapshin wrote:
>
>> Ulf told something about SDL, but I really don't know what is SDL.
>
> SDL = Specification and Description Language, is a ITU-T standard
> language for describing systems of communicating state machines. This
> was used much in Telecoms, and in real-time systems design, often
> together with Message Sequence Charts (MSC), to produce high-level
> systems architecture diagrams.
>
> SDL also extends down into programming with SDL/PR, but we can ignore
> that. ASN.1 - a loosely related data description layer - is however
> still quite relevant.
>
> In the great UML:ification, SDL was absorbed into UML. Before that, it
> became more and more object-oriented. Still, the earlier versions are
> actually fairly decent for describing erlang-based systems. In fact,
> it was once shown that a system described in SDL could be mapped 1:1
> over to Erlang. This has not been done much, since it was also easy to
> demonstrate that the same system could be more easily described in
> Erlang in the first place (although such a description would lose many
> of the qualities of a good system architecture description).
>
> Here is a tutorial of sdl88. The link jumps directly into something
> that ought to look familiar:
>
> http://www.sdl-forum.org/sdl88tutorial/4.ProcessCommunication/4.1_Signal_input_queue.htm
>
> Here's another overview:
> http://www.cs.nthu.edu.tw/~tanghome/SDTDoc/introsdl.html 
> <http://www.cs.nthu.edu.tw/%7Etanghome/SDTDoc/introsdl.html>
>
> BR,
> Ulf W
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111207/c6e3623b/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Andrew Thompson-3
In reply to this post by Fred Hebert
On Wed, Dec 07, 2011 at 05:21:13PM -0500, Fred Hebert wrote:

> On Wed, Dec 7, 2011 at 12:04 PM, Max Lapshin <max.lapshin> wrote:
>
> >
> > I have never ever seen any _production_ code, which is better with
> > gen_fsm. Thanks to Fred for study examples, but they are study
> > examples.
> >
> > I beleive that there may be situation, when gen_fsm is convenient. But
> > I ask only to show example of such code.
> >

Riak makes extensive use of FSMs in lots of places. A good example is the
put fsm:

https://github.com/basho/riak_kv/blob/master/src/riak_kv_put_fsm.erl

It's a FSM that models the states involved in writing a key to the
database. Of course, you *could* write this as a gen_server, but you'd
lose quite a bit of clarity.

Andrew


Reply | Threaded
Open this post in threaded view
|

OPL on Erlang (Was earlier "RE:Best practices in gen_fsm usage")

Avinash Dhumane-2
In reply to this post by Torben Hoffmann-3
>>>>

From: erlang-questions-bounces
[mailto:erlang-questions-bounces] On Behalf Of Torben Hoffmann



I think that Object Process Methodology (used lightly) and Message Sequence
Charts are better ways of structuring your high level thoughts.

>>>>

 

Hi Torben,

 

Found a reflection of my voice in you!

 

I am contemplating to compile a specification of what a system is and does
as stated using OPM/OPL, into (and run on) an Erlang AOS (Application
Operating System, as Joe puts it!).

 

There is some "impedance" mismatch between the "symbols" (ideas) of OPL and
Erlang, though in spirit, I (want to) believe that Erlang AOS is a perfect
(i.e. isomorphic) vehicle for materializing a "OPL system". To give some
examples:

1) A "process" of OPM is not an "Erlang process" - well, yes & no!

2) Moreover, an "OPM object" needs to find an expression in "Erlang process"
- again, yes & no!

3) OPM maintains the duality of "objects and processes", whereas Erlang
wants to see every_thing_ as a "process".

4) For OPM, "objects" are the things that are shaped and take shape, and
"processes" are the things that shape the objects - i.e. "shape" is both a
verb and noun. In Erlang, what gets shaped is also a process, and what
shapes is obviously a process.

5) I am not confident enough to say something on "state" in OPM and "state"
in Erlang.

 

My present view of world is as shown (& determined) by classic C with
Unix-IPC. I don't know other worlds. I haven't made much of progress in
Erlang AOS either, beyond few readings of Joe's thesis paper.

 

I am currently stuck on integrating the spirit of OPM/OPL and spirit of
Erlang AOS.

 

Is there some work going around in OPM and Erlang that can help me unlock
spiritually? Or, may I receive some help from you on how you materialize a
OPM-thought system into an Erlang system? Some directions are good enough -
I know otherwise this is a topic of a full volume.

 

Thank you

 

Kind regards

 

Avinash

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111209/545330a1/attachment.html>

Reply | Threaded
Open this post in threaded view
|

OPL on Erlang (Was earlier "RE:Best practices in gen_fsm usage")

Torben Hoffmann-3
Hi Avinash!

On 9/12/11 5:41 , Avinash Dhumane wrote:

>
> >>>>
>
> *From:*erlang-questions-bounces
> [mailto:erlang-questions-bounces] *On Behalf Of *Torben
> Hoffmann
>
> I think that Object Process Methodology (used lightly) and Message
> Sequence Charts are better ways of structuring your high level thoughts.
>
> >>>>
>
> Hi Torben,
>
> Found a reflection of my voice in you!
>
I had a hope that there was life out there... ;-)
>
> I am contemplating to compile a specification of what a system is and
> does as stated using OPM/OPL, into (and run on) an Erlang AOS
> (Application Operating System, as Joe puts it!).
>
> There is some "impedance" mismatch between the "symbols" (ideas) of
> OPL and Erlang, though in spirit, I (want to) believe that Erlang AOS
> is a perfect (i.e. isomorphic) vehicle for materializing a "OPL system".
>
I concur - I think OPM/OPL's way of describing systems fits very with
the way Joe refers to Erlang... the most object oriented language out
there!!

The major hurdle to get past when using OPM as an Erlanger is that
processes in OPM does not map to the Erlang processes as you also state it.

>
> To give some examples:
>
> 1) A "process" of OPM is not an "Erlang process" -- well, yes & no!
>
> 2) Moreover, an "OPM object" needs to find an expression in "Erlang
> process" -- again, yes & no!
>
> 3) OPM maintains the duality of "objects and processes", whereas
> Erlang wants to see every_thing_ as a "process".
>
> 4) For OPM, "objects" are the things that are shaped and take shape,
> and "processes" are the things that shape the objects -- i.e. "shape"
> is both a verb and noun. In Erlang, what gets shaped is also a
> process, and what shapes is obviously a process.
>
> 5) I am not confident enough to say something on "state" in OPM and
> "state" in Erlang.
>
I am not 100% in agreement with the way you map things here.

Let's start with "OPM object" which I think is best represented as an
Erlang process - I seem to recall that Joe also uses this "mapping" when
refering to Erlang as an object-oriented language.

"OPM processes" are functions in Erlang - when there are no side-effects
for an argument to a function then the "OPM process" consumes the
object. With side-effects in play the "OPM process" merely affects the
"OPM object".

It might be that there is a lot of talk about that everything in Erlang
is processes, but the functions are there too and they play a
significant r?le regardless of how you view the language.

State - in my interpretation - maps almost directly how state of an
Erlang process is handled.
>
> My present view of world is as shown (& determined) by classic C with
> Unix-IPC. I don't know other worlds. I haven't made much of progress
> in Erlang AOS either, beyond few readings of Joe's thesis paper.
>
Code a few programs and you will begin to see the world with different
eyes... I promise!!

> I am currently stuck on integrating the spirit of OPM/OPL and spirit
> of Erlang AOS.
>
> Is there some work going around in OPM and Erlang that can help me
> unlock spiritually?
>
Not that I am aware of - you could talk to Dov about it. I discussed a
few things with him some years ago, but I did not have enough time on my
hands to explore the topic further.
>
> Or, may I receive some help from you on how you materialize a
> OPM-thought system into an Erlang system? Some directions are good
> enough -- I know otherwise this is a topic of a full volume.
>
If you have a simple OPM example then you can send it to me on- or
off-line and then I will outline how I would map it to Erlang following
the general observations I made above. That exercise will be interesting.

At the moment I am using a small subset of OPM to document the
interactions between the entities of the systems I am developing. Just
objects and processes since that is enough to convey the major points of
the architecture - if I had to use UML or similar I would have to do at
least two diagrams in order to get both some static and dynamic
structure conveyed.

But please fire away and then I will help you get some more Erlang
semantics under your skin - I must guide aspiring Erlangers in order to
keep my ordination as Erlang Priest ;-)

Cheers,
Torben

>
> Thank you
>
> Kind regards
>
> Avinash
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111209/e103110e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Robert Virding-5
In reply to this post by Max Lapshin
Of course, you don't NEED gen_fsm as you can always carry an extra field in the loop data which indicates which state you are in. You can also flip that and say you don't really NEED gen_server as this is just a gen_fsm with one state.

The point is that using one or the other more clearly shows your intent and is therefore a Good Thing (tm).

I think this is also the with using send_all_state_event, it is an event which is allowed in all states. Of course, you can add a clause to each state function to handle that event, but using the send_all_state_event better shows the intent.

I don't really see why you would not wrap the actual gen_fsm:send_event/2 call in a user API, as you would do with gen_server:call/2. If you can hide the detail of the actual request being sent then you most often should do that.

Robert

----- Original Message -----

> On Wed, Dec 7, 2011 at 6:50 PM, Adam Lindberg
> <adam.lindberg> wrote:
>
> >
> > What exactly is the use case for being able to contact a process
> > that implements either gen_server or gen_fsm via a standard API?
> > I've never come across a use case where processes of different
> > "types" needed to be mixed. If you really, really have to have
> > that, you could implement a common interface via the handle_info/2
> > callbacks.
>
> You haven't met. I have.
>
> >
> > - Either your process runs code that is based on gen_fsm, then you
> > use a wrapper API that converts calls to corresponding gen_fsm
> > calls (just as Thomas suggested).
> >
>
> What for?
>
> I have never ever seen any _production_ code, which is better with
> gen_fsm. Thanks to Fred for study examples, but they are study
> examples.
>
> Ulf told something about SDL, but I really don't know what is SDL.
>
> I beleive that there may be situation, when gen_fsm is convenient.
> But
> I ask only to show example of such code.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|

Best practices in gen_fsm usage

Gianfranco Alongi-3
Agreeing totally with Robert here.

You should aim at making the underlying implementation transparent to
the user (9 times out of 10 this is myself).
This is a timeless good Software Engineering practice, you can keep
the API to the user and change the implementation from gen_fsm to
gen_server and your own homebrewn solution with ets tables and
whatnot.

/G

On Mon, Dec 12, 2011 at 4:20 PM, Robert Virding
<robert.virding> wrote:

> Of course, you don't NEED gen_fsm as you can always carry an extra field in the loop data which indicates which state you are in. You can also flip that and say you don't really NEED gen_server as this is just a gen_fsm with one state.
>
> The point is that using one or the other more clearly shows your intent and is therefore a Good Thing (tm).
>
> I think this is also the with using send_all_state_event, it is an event which is allowed in all states. Of course, you can add a clause to each state function to handle that event, but using the send_all_state_event better shows the intent.
>
> I don't really see why you would not wrap the actual gen_fsm:send_event/2 call in a user API, as you would do with gen_server:call/2. If you can hide the detail of the actual request being sent then you most often should do that.
>
> Robert
>
> ----- Original Message -----
>> On Wed, Dec 7, 2011 at 6:50 PM, Adam Lindberg
>> <adam.lindberg> wrote:
>>
>> >
>> > What exactly is the use case for being able to contact a process
>> > that implements either gen_server or gen_fsm via a standard API?
>> > I've never come across a use case where processes of different
>> > "types" needed to be mixed. If you really, really have to have
>> > that, you could implement a common interface via the handle_info/2
>> > callbacks.
>>
>> You haven't met. I have.
>>
>> >
>> > - Either your process runs code that is based on gen_fsm, then you
>> > use a wrapper API that converts calls to corresponding gen_fsm
>> > calls (just as Thomas suggested).
>> >
>>
>> What for?
>>
>> I have never ever seen any _production_ code, which is better with
>> gen_fsm. Thanks to Fred for study examples, but they are study
>> examples.
>>
>> Ulf told something about SDL, but I really don't know what is SDL.
>>
>> I beleive that there may be situation, when gen_fsm is convenient.
>> But
>> I ask only to show example of such code.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions


12