[erlang-questions] gen_statem state enter call and changing t oanother state

[Frans Schneider]

On 06/12/2018 12:31 PM, Ingela Andin wrote:
> Hi!
> 
> Could it be so that you are trying to solve the problem in the wrong 
> place? State enter actions are good for example starting a timer, but I 
> think it is illogical to change the state.
> It sound to me like you could do so pattern matching, maybe in 
> conjunction with some guards in the your state function clauses and if 
> your conditions are meet maybe
> all that clause does is to change state.
> 
> Regards Ingela Erlang/OTP team - Ericsson AB
> 
> 

Of course I can, but in this particular case it would lead to simpler 
code. For example, I have the following state changes defined ([1] par. 
8.4.12.2):

__|_____________|_____________________________|____________________
T2|waiting      |HEARTBEAT message is received|if (HB.FinalFlag ==
   |             |                             |    NOT_SET) then
   |             |                             |  must_send_ack else if
   |             |                             |   (HB.LivelinessFlag ==
   |             |                             |   NOT_SET) then
   |             |                             |  may_send_ack
   |             |                             |else
   |             |                             |  waiting
__|_____________|_____________________________|____________________
T3|may_send_ack |GuardCondition:              |waiting
   |             |   WP::missing_changes() ==  |
   |             |       <empty>               |
__|_____________|_____________________________|____________________
T4|may_send_ack |GuardCondition:              |must_send_ack
   |             |   WP::missing_changes() !=  |
   |             |       <empty>               |
__|_____________|_____________________________|____________________
T5|must_send_ack|after(R::heartbeatResponseDelay) waiting
__|_____________|_____________________________|____________________

Transitions T3/T4 are just begging for a enter state with next_state. 
The alternative would be to put the guard conditions at the end of T2, 
which of course is not that bad but it messes up the line of thinking of 
the original protocol designers and its readers. Also, T3/T4 could just 
become something like:

handle_event(enter,
	     _Old_state,
	     #state{state2 = may_send_ack} = State,
	     #data{missing_changes = []} = Data) ->
     {next_state, waiting, Data};
handle_event(enter,
	     _Old_state,
	     #state{state2 = may_send_ack} = State,
	     Data) ->
     ...
     {next_state, must_send_ack, Data};

which I think is very accurate. In the example, there is only T2 as the 
old state but there are other examples with more than one originating 
states.

Frans

[1] https://www.omg.org/spec/DDSI-RTPS/2.2/PDF

> 
> 2018-06-12 10:31 GMT+02:00 Frans Schneider <fchschneider@REDACTED 
> <mailto:fchschneider@REDACTED>>:
> 
> 
> 
>     On 06/12/2018 10:06 AM, Raimo Niskanen wrote:
> 
> 
>         I agree.  State enter calls were introduced to allow code to be
>         run when a
>         state is entered, without having to duplicate that code at every
>         state exit
>         from the previous state.  It is a feature existing in other
>         state machine
>         description languages e.g OpenBSD's ifstated.
> 
>     This is the exact reason for bringing up the whole issue. And
>     sometimes, that requires a next_state NewState.
> 
> 
> 
>     Frans
> 
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
> 
>