Finitomata - FSM boilerplate based on callbacks

@mudasobwa thanks for sharing this library, I’ve used gen_statem a few times in the past and I think your library makes these kinds of use-cases a lot more ergonomic. Have you ever thought making a compile-time dependency, rather than a runtime dependency?

My thought here is that I could use something like finitomata to help me develop a FSM module, but I could generate an elixir/erlang file with all of the expansion done so that I don’t have to specify finitomata as a dependency of my library. This also means that other libraries could use different versions of the tool without need to resolve to a shared version.

Just curious if you’ve considered a use-case like that, or maybe I should give it a try myself to see how it goes?

Well, there is no runtime dependency already, besides provided supervision subtree, registry, and helpers to deal with dynamic children.

If you don’t need all the above and are ready to manage the processes yourselves, you don’t depend on Finitomata in runtime. use Finitomata injects the code into your module in compile time. Generating this boilerplate code instead of injecting is not a big deal, a simple call to Macro.to_string/1 would do (e. g. from __before_compile__ callback.)

mix task to generate such a module is also trivial. I personally don’t like generators because the code they produce is hard to support, code injection works better. But I’d love to see a PR with a mix task generating the module.

FWIW, this thread contains links to other similar libraries and usage examples.

Thanks @mudasobwa your breakdown definitely improved my thinking. I can see how a generator might be a pain to deal with in source control etc. And the distinction between run-time, compile-time and deploy-time is helpful as well. Thanks again for the library, I’ll give it a run

After some hesitation, two new callbacks have been added.

• on_enter/2 — optional
• on_exit/2 — optional

Package published to finitomata | Hex
(25ec5990045d025fba2bb1c59a92e08fc8a045fdd347fcdcb885f22c75a1f2d2)

Introduces Infinitomata module as a drop-in replacement of Finitomata.{start_fsm/4,transition/4,state/3}. It transparently runs in a cluster, leveraging process groups :pg to keep track of spawned instances.

Example from tests:

defmodule InfinitomataTest do
  use ExUnit.Case, async: true
  @moduletag :distributed

  setup do
    {_peers, _nodes} = Enfiladex.start_peers(3) # start 3 peers
    Enfiladex.block_call_everywhere(Infinitomata, :start_link, [])
  end

  test "many instances (distributed)" do
    for i <- 1..10 do
      Infinitomata.start_fsm("FSM_#{i}", Finitomata.Test.Log, %{instance: i})
    end

    assert Infinitomata.count(Infinitomata) == 10

    for i <- 1..10 do
      Infinitomata.transition("FSM_#{i}", :accept)
    end

    assert %{"FSM_1" => %{}} = Infinitomata.all(Infinitomata)

    for i <- 1..10 do
      Infinitomata.transition("FSM_#{i}", :__end__)
    end

    Process.sleep(1_000)

    assert Infinitomata.count(Infinitomata) == 0 # all finished ending state
    assert Infinitomata.all(Infinitomata) == %{}
  end
end

Finitomata got Throttler, fully obsoleting Siblings.

Last version transparently runs on distributed erlang with the ability to throttle transitions, if necessary.

Another blog post about Finitomata.

To support my own rant about making our libraries test-friendly (based on finitomata example), I implemented the test scaffold generation, based on the FSM shape, collected during the compile time.

 mix finitomata.generate.test --module MyApp.FSM

The above would generate a scaffold for checking all the possible paths in the FSM declaration. Enjoy.

(this topic should have the finitomata tag)

I read your blog post about workflows, it was very interesting, thank you.

I never use libraries for FSMs because in my mind you don’t always know what is the next state when you handle an event. I think it’s weird to have both closed ‑- button press --> open and closed -- button press --> locked side by side, although it is the actual behaviour.

Probably I’m not using those tools correctly.

If you have some time, could you demo a door that opens when 4 digit button presses are correctly in order (the door code is 1234 obviously), but locks for 100ms seconds if 10 unsuccessful buttons are pressed (0001234 opens, 00011101234 locks the door after 3 and ignores presses for 30 sec so 4 is ignored). Door stays open for 50ms or so.

I could ask Claude to do it but I’d really like to see how you would do it!