<div dir="ltr"><div>Hi!</div><div><br></div><div>Then I think it sounds like you could have a help function to call when you leave the previous states to determine what should be the next state so that you make the "TM" right transition in the first place. <br></div><div>Or what am I not understanding?</div><div><br></div><div>Regards Ingela Erlang/OTP team Ericsson AB<br></div><div><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-06-12 14:14 GMT+02:00 Frans Schneider <span dir="ltr"><<a href="mailto:fchschneider@gmail.com" target="_blank">fchschneider@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 06/12/2018 12:31 PM, Ingela Andin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi!<br>
<br>
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.<br>
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<br>
all that clause does is to change state.<br>
<br>
Regards Ingela Erlang/OTP team - Ericsson AB<br>
<br>
<br>
</blockquote>
<br></span>
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):<br>
<br>
__|_____________|_____________<wbr>________________|_____________<wbr>_______<br>
T2|waiting |HEARTBEAT message is received|if (HB.FinalFlag ==<br>
| | | NOT_SET) then<br>
| | | must_send_ack else if<br>
| | | (HB.LivelinessFlag ==<br>
| | | NOT_SET) then<br>
| | | may_send_ack<br>
| | |else<br>
| | | waiting<br>
__|_____________|_____________<wbr>________________|_____________<wbr>_______<br>
T3|may_send_ack |GuardCondition: |waiting<br>
| | WP::missing_changes() == |<br>
| | <empty> |<br>
__|_____________|_____________<wbr>________________|_____________<wbr>_______<br>
T4|may_send_ack |GuardCondition: |must_send_ack<br>
| | WP::missing_changes() != |<br>
| | <empty> |<br>
__|_____________|_____________<wbr>________________|_____________<wbr>_______<br>
T5|must_send_ack|after(R::hear<wbr>tbeatResponseDelay) waiting<br>
__|_____________|_____________<wbr>________________|_____________<wbr>_______<br>
<br>
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:<br>
<br>
handle_event(enter,<br>
_Old_state,<br>
#state{state2 = may_send_ack} = State,<br>
#data{missing_changes = []} = Data) -><br>
{next_state, waiting, Data};<br>
handle_event(enter,<br>
_Old_state,<br>
#state{state2 = may_send_ack} = State,<br>
Data) -><br>
...<br>
{next_state, must_send_ack, Data};<br>
<br>
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.<br>
<br>
Frans<br>
<br>
[1] <a href="https://www.omg.org/spec/DDSI-RTPS/2.2/PDF" rel="noreferrer" target="_blank">https://www.omg.org/spec/DDSI-<wbr>RTPS/2.2/PDF</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2018-06-12 10:31 GMT+02:00 Frans Schneider <<a href="mailto:fchschneider@gmail.com" target="_blank">fchschneider@gmail.com</a> <mailto:<a href="mailto:fchschneider@gmail.com" target="_blank">fchschneider@gmail.com</a><wbr>>>:<span class=""><br>
<br>
<br>
<br>
On 06/12/2018 10:06 AM, Raimo Niskanen wrote:<br>
<br>
<br>
I agree. State enter calls were introduced to allow code to be<br>
run when a<br>
state is entered, without having to duplicate that code at every<br>
state exit<br>
from the previous state. It is a feature existing in other<br>
state machine<br>
description languages e.g OpenBSD's ifstated.<br>
<br>
This is the exact reason for bringing up the whole issue. And<br>
sometimes, that requires a next_state NewState.<br>
<br>
<br>
<br>
Frans<br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br></span>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlan<wbr>g.org</a>><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
<<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/lis<wbr>tinfo/erlang-questions</a>><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div></div></div></div>