[tejasv]

Here's is a simplistic example of a state machine:

  let transition (state: State) (action: Action) : State option =
     match (state, action) with
     | (StateA, ActionA) -> Some StateB
     | (StateA, ActionB) -> Some StateC
     | (StateB, ActionA) -> Some StateB
     | _ -> None

If you get the quoted representation of the transition function, it can be visualized as a tree data structure (like code-as-data in LISP). You can analyze that tree to understand that if current state is StateB, only ActionA can be applied on it.

Couple this with another realization: "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

This means all the entity framework/ORM crap work that we do can actually be neatly represented as transforms on a F# state machine, which suddenly makes the application more powerful if you give it this structure.

We use this technique to auto-generate admin panels.

[skue]

> "Any sufficiently complicated model class contains an ad hoc, informally specified, bug-ridden, slow implementation of half of a state machine." (not sure where I read this quote).

Can’t tell you where you read it, of course, but believe it originates from Braithwaite/raganwald:

http://raganwald.com/2018/02/23/forde.html

[xupybd]

Do you blog any of this or do any sort of writing on the topic. I think I could learn a lot from the way you are doing things.

[tejasv]

Not yet, it has been on my list for a long time. Meanwhile I recommend this blog that collates all good F# content from around the web weekly:

https://sergeytihon.com/category/f-weekly/