Re:Finite State Machines
by user-the-name on Monday February 22, 2021 @08:16AM
(#26224127)
That means you are not able to interrupt your state machine easily, or to serialise its state. That might be OK in a lot of cases, but not all.
Function objects, including closures, can be serializable - they are in Erlang/Elixir. You can send a lambda/closure over to another node (on another machine) to execute. It's actually one of the basic building blocks of OTP.
Re:Finite State Machines
by user-the-name on Monday February 22, 2021 @11:19AM
(#26226248)
I assume this only works if the functions are exactly the same. It would break between different versions?
Re:Finite State Machines
by rad_gruchalski on Monday February 22, 2021 @05:24PM
(#26231503)
It depends. It’s possible to provide a mechanism to switch versions but as it very often is: there are dragons.
Seems like trampolining would be useful to make it interruptible while still mostly preserving the ergonomics of viewing state transitions as procedure calls
Re:Finite State Machines
by dragonwriter on Monday February 22, 2021 @11:23AM
(#26226300)
Serializable closures (even serializable continuations) are available in a number of languages, including probably most often ones which also have TCO.
What is TCO?
what are languages that implement TCO?
Tail Call Optimization, better called Tail Call Elimination. Haskell, OCaml, Erlang/Elixir, Scala with @tailrec, Scheme, Lua(!), most other functional languages.
Basically, if there's a call to a function B at the very end of function A, there's no need to create a new stack frame for the call to B - you can reuse the frame created for call to A. It both saves memory and improves performance. A special case is when A and B are both the same function, in which case we say A is tail-recursive.
The difference is small, but once you start getting hairy state machines I have found that it leads to smaller mental overhead for me.
The same would be true for something like a recursive descent parser.