DEV Community

Modelling domain with state machines in ReasonML

Margarita Krutikova on May 03, 2020

Today we are going to focus on modelling state and state handling logic of a system in a functional way, without touching the user interface. The...

Read full post

Iven Marquardt • May 3 '20 • Edited

What interests me is the connection of tagged unions and state machines. With tagged unions you can model values that depend on each other. An asynchronous task, for instance, can either be resolved with a value or rejected with a reason. But it cannot be both or neither. With a tagged union we can rule out the last two invalid states of such a task. This seems to be halfway to a state machine.

Janne Siera • May 3 '20

That's exactly what's meant by "making impossible states unrepresentable" at the beginning of this article.

State machines have two things: states and transitions. With algebraic data types (tagged unions + records) we can model a state machine's states so that only valid states are represented. The next step would be to also model the transitions this way so that both invalid states as invalid transitions are excluded. This is also possible, but your code gets bloated quickly because you have to explicitly model every state and transition.

Margarita Krutikova • May 3 '20

That's interesting. Could you give a code example of how tagged unions can model values that depend on each other? And also how you can rule out the last two invalid states.

Iven Marquardt • May 3 '20 • Edited

I don't know ReasonML but I guess it has an Either type, right? Either<A, B> has two value constructors Left/Right, which can produce values of type Either<SomeProperType, B> and Either<A, SomeProperType> respectively. Consequently you cannot produce the invalid values Either<A, B> (no value at all) or Either<SomeProperType, SomeProperType (both values at the same time, aka the product). These values or states are ruled out by the way you modelled the data by using a tagged union. Values produced by Left and Right depend on each other, because they are mutually exclusive.

Austin • May 5 '20 • Edited

That's a pretty good description of the way variants work. OCaml/Reason does not have a built-in Either type, but they do have this "disjoint tagged unions" which can behave the same way.

The most common data type that models the Either type you describe (used in Haskell) is the Result type. It is modeled using the variant constructors Ok and Error. So the Reason code would look like:

module Result = {
  type t('a, 'e) =
    | Ok('a)
    | Error('e);
};

And the type we have there is a bifunctor and a monad, just like Either.

Gabriel Rubens Abreu • May 3 '20

Great write up, Margarita!

Margarita Krutikova • May 3 '20

Thank you! 🙂

Yawar Amin • May 3 '20

Fantastic! Looking forward to the next one 🙂

Margarita Krutikova • May 3 '20

Thank you! Great to have so much feedback from the community 🙂

JP Lew • May 26 '20

Great article, I'm new to state machines and learned a lot.

In the last slide of your Stockholm talk, you shared some F# articles that you found useful. Can you link them here?

Margarita Krutikova • May 26 '20

Thank you!
Here are the articles:
fsharpforfunandprofit.com/posts/de...
fsharpforfunandprofit.com/posts/de...

And the original slides slides.com/margaretkru/state-machi...

Real AI • Feb 27 '21

StateM is a Monad !