State machine to FRP code

[jhegedus42]

Is there a general/algorithmic way to transcribe a state machine specification/diagram to an FRP code ?

Say, I describe a state machine in a diagram, how can I tell what is that simplest FRP code that corresponds to it ?

[the-real-blackh]

In state machine diagrams where each box represents a different state, this would be represented by a single cell of an enumerated type with a name for each box. The cell would be defined as the hold of the merge of all state transitions, initiated by external events, each of which is represented by a stream.

[jhegedus42]

Right, but isn't it so that FRP is especially well suited for describing state machines in a more DRY (concise) way?

I mean state machines can be described/encoded by state transition tables or by some kind of higher level functions.

For example, say I have a state machine where the possible inputs are the digits 1 to 10 and we have two states, A and B. The rule for transition is that if the sum of the last ten inputs digits is prime then we transition, otherwise not.

Anyway, maybe this is not the best example, but I was just wondering what would be a good example where FRP would shine, in contrast to more traditional approaches (for example UML statecharts).

What would be a good example/problem that would be easier/more concise/more elegant/ more DRY to describe/define/reason about using FRP than UML statecharts (the traditional/mainsream way) ?

How would the reactive petrol pump compare in this respect (for example) ?

What class of ( reactive ) problems can be "better" described with FRP than with statecharts/UML ?

[the-real-blackh]

Hi,

State transition diagrams would translate directly to FRP. Whereas, a C program isn't ever going to be equivalent to a state transition diagram in the same way.

Presumably state transition diagrams don't deal so well with state that isn't a position in the diagram. I had an example come up at work: a battery-charging state machine. It had a positional state of not charging, slow charging, and fast charging. It also had to deal with time. This is represented directly in FRP but presumably becomes an annotation on a state diagram. I am not an expert in state machine diagramming.

So maybe this is one example where FRP does better. A video game is an example of the same kind of thing, but more complex. In terms of state transition diagrams, this would require many of them linked together.

So FRP isn't really better, as such. It's the same idea but both complete (in that any program can be written in it) and distilled down to its fundamental essence. If state transition diagrams were complete in the same way I'd expect them to be basically equivalent to FRP.

Steve

[dakom]

Fwiw, in 15.7-8 in the book, the authors mention visual programming and debugging tools as a possible future direction of FRP, and the earlier chapters introduce the primitives via easy-to-grasp charts.... I don't think anyone's built tooling around this yet, but it seems like an interactive sort of chart would be great not just for describing the flow but for hands-on development as well...

[dakom]

Oh interesting - when I first saw this post I read "statecharts" as "state charts"... now looking at the upcoming trend of "Statecharts" as like a specific mechanism - even with a spec done by committee, I wonder if this will gain traction.

Specifically it seems xstate is gaining traction and I'm planning to tinker around with it for an upcoming app: https://github.com/davidkpiano/xstate

Would be interesting if the same spec for designing the machines can output FRP code (in addition to being parsed by xstate and feeding into their visualization tool)

[clinuxrulz]

I will add something. Sometimes you can dodge the enum State part, if the intent of the state machine is for gathering information.

Normally:

enum State = { State1, State2, ... };
let cState: Cell<State>

Then wire everything up, and use Stream::gate everywhere to insure information the correct information is passed around for each stage.

Alternatively: If the information your gathering is sequenial you can avoid the State enum, using StreamLoops.

E.g.

let slInfo1Op = new StreamLoop<Option<Info1>>();
let cInfo1Op = slInfo1.hold(Option.none());
slInfo1Op.loop( your logic gated against cInfo1Op.map(x => x.isNone)
let slInfo2Op = new StreamLoop<Option<Info2>>();
let cInfo2Op = slInfo2.hold(Option.none());
slInfo2Op.loop( your logic gated against cInfo2Op.map(x => x.isNone)

etc. And you get a flow-on sequential effect like a state-machine, but without the need for enum State.