POE::NFA(3pm)

💖 POE::NFA 💖

okay bestie, welcome to POE::NFA(3pm) — a whole manual page from the User Contributed Perl Documentation corner of the universe, and honestly? it's giving legend behaviour. sit down, grab a strawberry, we're doing state machines 🍓✨

---

🌸 NAME 🌸

POE::NFA — an event-driven state machine (nondeterministic finite automaton). yes the acronym is a mouthful, no we are not shortening it, it's iconic 💅

---

✨ SYNOPSIS ✨

like, here's the whole vibe in one go. don't panic, we'll walk through it:

use POE::Kernel;
use POE::NFA;
use POE::Wheel::ReadLine;

# Spawn an NFA and enter its initial state.
POE::NFA->spawn(
  inline_states => {
    initial => {
      setup => \&setup_stuff,
    },
    state_login => {
      on_entry => \&login_prompt,
      on_input => \&save_login,
    },
    state_password => {
      on_entry => \&password_prompt,
      on_input => \&check_password,
    },
    state_cmd => {
      on_entry => \&command_prompt,
      on_input => \&handle_command,
    },
  },
)->goto_state(initial => "setup");

POE::Kernel->run();
exit;

sub setup_stuff {
  $_[RUNSTATE]{io} = POE::Wheel::ReadLine->new(
    InputEvent => 'on_input',
  );
  $_[MACHINE]->goto_state(state_login => "on_entry");
}

sub login_prompt { $_[RUNSTATE]{io}->get('Login: '); }

sub save_login {
  $_[RUNSTATE]{login} = $_[ARG0];
  $_[MACHINE]->goto_state(state_password => "on_entry");
}

sub password_prompt { $_[RUNSTATE]{io}->get('Password: '); }

sub check_password {
  if ($_[RUNSTATE]{login} eq $_[ARG0]) {
    $_[MACHINE]->goto_state(state_cmd => "on_entry");
  }
  else {
    $_[MACHINE]->goto_state(state_login => "on_entry");
  }
}

sub command_prompt { $_[RUNSTATE]{io}->get('Cmd: '); }

sub handle_command {
  $_[RUNSTATE]{io}->put("  <<$_[ARG0]>>");
  if ($_[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {
    $_[RUNSTATE]{io}->put('Bye!');
    $_[MACHINE]->stop();
  }
  else {
    $_[MACHINE]->goto_state(state_cmd => "on_entry");
  }
}

---

🦋 DESCRIPTION 🦋

POE::NFA is a different kind of POE session — a non-deterministic finite automaton. let's break that down, because the name is doing a lot 😭

a finite automaton is a state machine with a bounded number of states and transitions. technically, POE::NFA objects can modify themselves at run time, so they aren't really "finite". but run-time modification isn't currently supported by the API, so plausible deniability is maintained! 👑 (this is the most unserious sentence in the whole page and I respect it deeply)

Deterministic state machines are the ones where all possible transitions are known at compile time. POE::NFA is "non-deterministic" because transitions may change based on run-time conditions. that's the whole plot twist ✨

but like, more simply? POE::NFA is basically POE::Session but with banks of event handlers that can get swapped around depending on the session's run-time state. look at the SYNOPSIS example — it has "on_entry" and "on_input" handlers that do completely different things depending on the run-time state. POE::Wheel::ReadLine throws "on_input", but the vibe is totally different depending on whether the session is in its "login", "password" or "command" state. same event, different girl 💅

POE::NFA borrows heavily from POE::Session, so this doc is only gonna talk about the differences. for anything that's similar, go read POE::Session. periodt.

---

🌈 PUBLIC METHODS 🌈

this doc is mostly about how these differ from POE::Session, okay? okay.

🎀 get_current_state

every machine state has a name. get_current_state() returns the name of the machine's current state.

get_current_state() is mainly for retrieving the state of some other machine. but if you're inside a machine's own event handlers, it's easier (and faster) to just use $_[STATE]. bestie, take the shortcut 🫶

🎀 get_runstate

get_runstate() returns the machine's current runstate. runstates are equivalent to POE::Session HEAPs, so this method does pretty much exactly what POE::Session's get_heap() does.

that said — inside a machine's own event handlers, it's easier (and faster) to use $_[RUNSTATE]. again: shortcut, take it ✨

🎀 spawn STATE_NAME => HANDLERS_HASHREF[, ...]

spawn() is POE::NFA's constructor. the name reflects the idea that new state machines are spawned like threads or processes, rather than instantiated like objects. it's giving birth, not factory 🐣

the machine itself is defined as a list of state names and hashes that map events to handlers within each state:

my %states = (
  state_1 => {
    event_1 => \&handler_1,
    event_2 => \&handler_2,
  },
  state_2 => {
    event_1 => \&handler_3,
    event_2 => \&handler_4,
  },
);

a single event may be handled by many states. the proper handler gets called depending on the machine's current state. for example, if "event_1" is dispatched while the machine is in "state_2", then handler_3() will be called to handle the event. the state -> event -> handler map looks like this:

$machine{state_2}{event_1} = \&handler_3;

instead of "inline_states", you can use "object_states" or "package_states". these map the events of a state to an object or package method respectively:

object_states => {
  state_1 => [
    $object_1 => [qw(event_1 event_2)],
  ],
  state_2 => [
    $object_2 => {
      event_1 => method_1,
      event_2 => method_2,
    }
  ]
}

in the example above, in the case of "event_1" coming in while the machine is in "state_1", method "event_1" will be called on $object_1. if the machine is in "state_2", method "method_1" will be called on $object_2. slay, polymorphism 💖

"package_states" is very similar, but instead of using an $object, you pass in a "Package::Name".

the "runstate" parameter lets "RUNSTATE" be initialized differently at instantiation time. "RUNSTATE", like heaps, are usually anonymous hashrefs — but "runstate" may set them to be array references or even objects. no cap 👑

state transitions are not necessarily executed immediately by default. instead, they're placed in POE's event queue behind any currently pending events. enabling the "immediate" option causes state transitions to occur immediately, regardless of any queued events. so like, know which one you want 🌸

🎀 goto_state NEW_STATE[, ENTRY_EVENT[, EVENT_ARGS]]

goto_state() puts the machine into a new state. if an ENTRY_EVENT is specified, that event gets dispatched after the machine enters the new state. EVENT_ARGS, if included, get passed to the entry event's handler via "ARG0..$#_".

# Switch to the next state.
$_[MACHINE]->goto_state( 'next_state' );

# Switch to the next state, and call a specific entry point.
$_[MACHINE]->goto_state( 'next_state', 'entry_event' );

# Switch to the next state; call an entry point with some values.
$_[MACHINE]->goto_state( 'next_state', 'entry_event', @parameters );

🎀 stop

stop() forces a machine to stop. the machine will also stop gracefully if it runs out of things to do, just like POE::Session. it knows when to leave the party 🫶

stop() is heavy-handed. it will force resources to be cleaned up. however, circular references in the machine's "RUNSTATE" are not POE's responsibility and may cause memory leaks. so like, watch your references bestie, that's on you 💀

$_[MACHINE]->stop();

🎀 call_state RETURN_EVENT, NEW_STATE[, ENTRY_EVENT[, EVENT_ARGS]]

call_state() is similar to goto_state(), but it pushes the current state on a stack. at some later point, a handler can call return_state() to pop the call stack and return the machine to its old state. at that point, a "RETURN_EVENT" will be posted to notify the old state of the return. it's giving "brb" with a full audit trail ✨

$machine->call_state( 'return_here', 'new_state', 'entry_event' );

as with goto_state(), "ENTRY_EVENT" is the event that will be emitted once the machine enters its new state. "ENTRY_ARGS" are parameters passed to the "ENTRY_EVENT" handler via "ARG0..$#_".

🎀 return_state [RETURN_ARGS]

return_state() returns to the most recent state in which call_state() was invoked. if the preceding call_state() included a return event, then its handler will be invoked along with some optional "RETURN_ARGS". the "RETURN_ARGS" will be passed to the return handler via "ARG0..$#_".

$_[MACHINE]->return_state( 'success', @success_values );

🎀 Methods that match POE::Session

the following methods behave identically to the ones in POE::Session:

• ID
• option
• postback
• callback

🎀 About new() and create()

POE::NFA's constructor is spawn(), not new() or create(). say it with me: spawn(). 📣

---

💜 PREDEFINED EVENT FIELDS 💜

POE::NFA's predefined event fields are the same as POE::Session's, with the following three exceptions:

🌟 MACHINE

"MACHINE" is equivalent to Session's "SESSION" field. it holds a reference to the current state machine, and is useful for calling its methods.

see POE::Session's "SESSION" field for more information.

$_[MACHINE]->goto_state( $next_state, $next_state_entry_event );

🌟 RUNSTATE

"RUNSTATE" is equivalent to Session's "HEAP" field. it holds an anonymous hash reference which POE is guaranteed not to touch. data stored in "RUNSTATE" will persist between handler invocations. it's yours, bestie, POE won't go through your stuff 💅

🌟 STATE

"STATE" contains the name of the machine's current state. it is not equivalent to anything from POE::Session. she's original, she's one of a kind ✨

🌟 EVENT

"EVENT" is equivalent to Session's "STATE" field. it holds the name of the event which invoked the current handler. see POE::Session's "STATE" field for more information. (yes, the names cross over. no, I don't make the rules 😭)

---

🔥 PREDEFINED EVENT NAMES 🔥

POE::NFA defines four events of its own. these events are used internally and may not be overridden by application code.

see POE::Session's "PREDEFINED EVENT NAMES" section for more information about other predefined events.

the events are: "poe_nfa_goto_state", "poe_nfa_push_state", "poe_nfa_pop_state", "poe_nfa_stop".

yes, all the internal events begin with "poe_nfa_". more may be forthcoming, but they will always begin the same way. therefore please do not define events beginning with "poe_nfa_". that namespace is taken, bestie, it's reserved 🙈

---

🌸 SEE ALSO 🌸

many of POE::NFA's features are taken directly from POE::Session. please see POE::Session for more information.

the SEE ALSO section in POE contains a table of contents covering the entire POE distribution. go explore, it's a whole world 🦋

---

💀 BUGS 💀

see POE::Session's documentation.

POE::NFA is not as feature-complete as POE::Session. your feedback is appreciated. ngl, they're literally asking for input — if you find something, tell them 🫶

---

👑 AUTHORS & COPYRIGHTS 👑

please see POE for more information about authors and contributors.

---

and that's the whole page, bestie!! you read all of it, which is main character energy fr fr 💖

tiny sign-off because the footer said so: this page is POE::NFA(3pm), from perl v5.34.0, dated 2022-03-25. yes that date is old, and yes the docs still ate. periodt. ✨🎀💅