Expressing a boolean expression as a finite state machine - boolean

Question

Is it possible to express a boolean expression as a finite state machine such that the FSM accepts an input that matches the boolean expression ?
Is it possible to merge multiple such FSMs, and upon acceptation, to know which original FSM did match ?
Background: I'm trying to evaluate a lot of boolean expressions at once. I'm thinking that with the correct representation, maybe a DFA could do that super efficiently (i.e. better than O(n) with n = number of expressions).

Answer 1

I know this is a very old question but I did find myself in similar situations and I think there are some cases where an FSM might offer some help in complex boolean logic.
One example I outlined in a blog post of mine where I described the use of a state machine while walking (looping) through the tokens of a simple string.
The advantage in this case was that instead of each token in the parsing process having a dedicated boolean flag which other paths in the syntax tree would need to guard against I could just feed each token as an event to the FSM and let the machine fall into different states. I used Statechart actions to build up little op-codes while it was processing and then finally based on the final state either abort or go on to compiling the generated op-codes.
You will have to read the article to gain a context of what I said above. But the gist of it is that in some cases a series of booleans could be converted to event names and passed to an FSM for processing. In another example I had to choose which UI state I needed to render based on a set of overwhelming boolean logic.
Because some flags took precedence over others the resulting logic tree looked like this:
Figure 1 — example UML activity diagram
Which resulted in code that looked a bit like this:
Figure 2 — complex boolean logic code
let presenterFlags = {
showSpecialTypeTab: model.type === 'special',
showDefaultWarning: (model.type === 'special' && model.isDefault && !settings.enforced),
showDefaultInBrokenStateWarning: (model.type === 'special' && model.isDefault && settings.enforce),
disableSaveButton: (model.type === 'special' && model.isDefault && !settings.enforce) || !model.canWrite,
disableCancelButton: (model.type === 'special' && model.isDefault && !settings.enforce) || !model.canWrite,
disableDeleteButton: (model.type === 'special' && model.isDefault) || !model.canWrite,
disableEnforcementToggle: (model.type === 'special' && model.isDefault && !settings.enforced) || !model.canWrite,
disableAnotherToggle: (model.type === 'special' && model.isDefault) || !model.canWrite,
};
Which to me was too much for my brain to bear. So I leaned on the use of an FSM which resulted in a State diagram like:
Figure 3 — example UML State diagram
Using XState the code might have looked like this:
Figure 4 — example XState machine
let booleanMachine = Machine({
id: 'ExamplePresentationFlags',
strict: true,
initial: 'conditional',
context: {},
states: {
conditional: {
on: {
'EVALUATE': [
{ target: 'SpecialExample', cond: 'isSpecialExample' },
{ target: 'GenaricExample' },
],
},
},
GenaricExample: {
initial: 'conditional',
states: {
conditional: {
on: {
'': [
{ target: 'ReadOnly', cond: 'canNotWrite' },
{ target: 'Default', cond: 'isDefault' },
{ target: 'Writable' },
],
},
},
Writable: {},
Default: {},
ReadOnly: {
meta: {
disableSaveButton: true,
disableCancelButton: true,
disableDeleteButton: true,
},
},
},
},
SpecialExample: {
initial: 'conditional',
meta: { showSpecialTypeTab: true },
states: {
conditional: {
on: {
'': [
{ target: 'ReadOnly', cond: 'canNotWrite' },
{ target: 'Default', cond: 'isDefault' },
{ target: 'Writable' },
],
},
},
Writable: {},
ReadOnly: {
meta: {
disableSaveButton: true,
disableCancelButton: true,
disableDeleteButton: true,
disableAnotherToggle: true,
},
},
Default: {
initial: 'conditional',
states: {
conditional: {
on: {
'': [
{ target: 'Enforced', cond: 'isEnforced' },
{ target: 'Unenforced' },
],
},
},
Unenforced: {
meta: {
exampleWarning: 'default-read-only',
disableSaveButton: true,
disableCancelButton: true,
disableDeleteButton: true,
disableAnotherToggle: true,
},
},
Enforced: {
meta: {
exampleWarning: 'special-default-broken-enforce-state',
disableSaveButton: false,
disableCancelButton: false,
disableDeleteButton: true,
disableAnotherToggle: true,
},
},
},
},
},
},
},
}, {
guards: {
isSpecialExample: (ctx) => ctx.exampleType === 'special',
canNotWrite: (ctx) => !ctx.canWrite,
isEnforced: (ctx) => ctx.isEnforced,
isDefault: (ctx) => ctx.isDefault,
isNotDefault: (ctx) => !ctx.isDefault,
},
});
With a reducer like function:
Figure 5 — example XState reducer function
function presentorFlags({ canWrite, model, settings }) {
let machine = booleanMachine.withContext({
canWrite,
exampleType: model.type,
isEnforced: settings.enforced,
isDefault: model.isDefault,
});
let { meta } = machine.transition(machine.initialState, 'EVALUATE');
return Object.keys(meta)
.reduce((acc, key) => ({ ...acc, ...meta[key] }), {});
}
Understand that I agree this example is unconventional and also bigger. It did provide me the ability to understand the logic especially with the visualization tools at hand (i.e. Figure 3). At the time it allowed me to conceptualize all the edge case states and not have to worry about what each state of the UI meant as far as view code was concerned. Instead I could focus on the states themselves and what logic would get the machine into that state. Then I gave the reducer the actual boolean values and let the machine do the work. What I get back is just a set of UI flags that is easy to place in my template.
Again, maybe this is not better or maybe it is. The point is that it is possible to use a state machine to express boolean logic.