3 ms·
It's interesting that both the question and the answer do focus on pattern matching. I maybe mistaken on this but that is really just one use of FSMs. I've im
by martinced 14y ago
It's interesting that both the question and the answer do focus on pattern matching. I maybe mistaken on this but that is really just one use of FSMs.
I've implement event-driven FSMs and to me the biggest "ah ah" moment was that it was trivial to make a list of valid (or non valid) state transitions. I used it in one particular case which was really complex (IMHO) to model and were my code was quickly becoming a gigantic mess. I ended up rewriting that part using an event-driven FSM and things became smooth.
Nowadays I don't like the 'S' in "FSM" that much anymore: I've moved to FP and can't really say I'm missing mutability.
- stuffihavemade 14y agoYou still create FSM's in functional languages though. Consider: data Light = On | Off toggle :: Light -> Light toggle On = Off toggle Off = On So, the data structures represent the possible states, and the associated functions the transitions.
- chas 14y agoI don't think you need to abandon the S. I think FSMs embody the core of functional thinking. Structuring your computation as a FSM splits your code into your current state and a combinatorial logic block that takes a current state and outputs a new state along with some optional side-effects. Splitting your computations into pure functions that hold state on their end-points sounds very much like the philosophy behind FP.