Hierarchical Concurrent State Machine

[aleneum]

Hi,

I have not worked with transitions so far but it looks like a really neat and pythonic approach to state machines. So in that matter its exactly what we need for a project :). My question is if transitions also supports nested and concurrent states. I know it is a bit contradicting to search something 'simple' but also requiring such complex features. But maybe I have just missed that in the docs or you may have some recommendations about how to realise hierarchical concurrent state machines with transitions.

Best regards,
Alex

[tyarkoni]

Thanks for the question, @aleneum! Support for hierarchical states has been suggested before (#31); to recap: I think it would be nice, as long as the implementation can be made relatively compact. I'm happy to consider PRs or to discuss potential implementations, but probably won't have time to implement this myself any time soon, so it would fall to someone else to do it.

With respect to concurrent states, it depends on what you mean. If you mean support for being in multiple states at once, but still in a single-threaded context, I'm willing to consider something along those lines---though I'd need to be convinced that there's a real need for it. I guess my intuition is that most potential use cases could be reduced to either (i) making states hierarchical (so, this amounts to implementing hierarchies, as above), (ii) implementing multiple Machine instances, or (iii) refactoring the states so that you encode all possible combinations of desired states as discrete states.

On the other hand, if you're talking about concurrency in the sense of multithreading (see discussion in #30), then that's definitely not on the agenda, as I think it would be a beast to get right.

Since this has come up before, I'll mark it as help wanted and leave it open.

[aleneum]

Thank you for your fast and detailed answer. I missed to check the closed issues. My thoughts went into the same direction as described in #31 and I would be happy to contribute (or at least give it a shot) if you consider this a promising road.

About concurrency: I agree with you that in most cases its preferable to redesign rather than using concurrency. Since it is problematic not just on the programatic level. It's also tough to debug and hard to comprehend and follow, especially if you have not worked with the code before.

It just seems to be a required and used feature in our robotic department (which also looks for a new state machine). I better check with the guys again about what they need. I assume they have cases like:

planTrip ----> checkEnvironment
    |                 |
    V                 V
checkSelf ------>  doTrip

where multiple settings and sensors have to be prepared and checked before something can be done. So yeah, the execution context is probably multithreaded, distributed and hell. I guess thats why they also want to rework they current solution :).

Thank you for your input so far. I will tinker around a bit and if we decide to build upon transitions I will probably contact you again.

Best regards,
Alex

[tyarkoni]

Added in b327706. Thanks again, @aleneum!