<div dir="ltr">Hi!<br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 5:47 PM Frans Schneider <<a href="mailto:fchschneider@gmail.com">fchschneider@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 06/11/2018 05:15 PM, Raimo Niskanen wrote:<br>> But there are still some hairy semantics to get right:<br>
> * If changing states in state_enter call hops more than once - what should<br>
>    OldState be after the first state_enter call?  I.e how much of a state<br>
>    change should changing states in the state_enter call be regarded as.<br>
>    As the gen_statem code looks now it seems to be easier to retain<br>
>    the original OldState and not regard the state change as complete until<br>
>    the final state of the state change has been deduced.<br>
<br>
Yes, I would expect a cascade of state enter calls with OldState <br>
reflecting the states it goes through.<br></blockquote><div><br></div><div>I am not a state machine expert, so maybe I am misunderstanding. If we allow jumping to arbitrary states from state_enter, isn't it like there is another state embedded there? </div><div><br></div><div>One of the advantages of state machines is that it's easy to see from the code where the continuations are. One can no longer tell from examining the source state what states follow it, but one has to examine the state_enter of all these first.</div><div><br></div><div>Isn't it cleaner to just separate this complex state into several simpler ones? Or am I missing something?</div><div><br></div><div>best regards,</div><div>Vlad</div><div> </div></div></div>