{
    "content": [
        {
            "type": "text",
            "text": "# POE::NFA (perldoc)\n\n## NAME\n\nPOE::NFA - an event-driven state machine (nondeterministic finite automaton)\n\n## SYNOPSIS\n\nuse POE::Kernel;\nuse POE::NFA;\nuse POE::Wheel::ReadLine;\n# Spawn an NFA and enter its initial state.\nPOE::NFA->spawn(\ninlinestates => {\ninitial => {\nsetup => \\&setupstuff,\n},\nstatelogin => {\nonentry => \\&loginprompt,\noninput => \\&savelogin,\n},\nstatepassword => {\nonentry => \\&passwordprompt,\noninput => \\&checkpassword,\n},\nstatecmd => {\nonentry => \\&commandprompt,\noninput => \\&handlecommand,\n},\n},\n)->gotostate(initial => \"setup\");\nPOE::Kernel->run();\nexit;\nsub setupstuff {\n$[RUNSTATE]{io} = POE::Wheel::ReadLine->new(\nInputEvent => 'oninput',\n);\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\nsub loginprompt { $[RUNSTATE]{io}->get('Login: '); }\nsub savelogin {\n$[RUNSTATE]{login} = $[ARG0];\n$[MACHINE]->gotostate(statepassword => \"onentry\");\n}\nsub passwordprompt { $[RUNSTATE]{io}->get('Password: '); }\nsub checkpassword {\nif ($[RUNSTATE]{login} eq $[ARG0]) {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\nelse {\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\n}\nsub commandprompt { $[RUNSTATE]{io}->get('Cmd: '); }\nsub handlecommand {\n$[RUNSTATE]{io}->put(\"  <<$[ARG0]>>\");\nif ($[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {\n$[RUNSTATE]{io}->put('Bye!');\n$[MACHINE]->stop();\n}\nelse {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\n}\n\n## DESCRIPTION\n\nPOE::NFA implements a different kind of POE session: A non-deterministic finite automaton. Let's\nbreak that down.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **PUBLIC METHODS** (8 subsections)\n- **PREDEFINED EVENT FIELDS**\n- **PREDEFINED EVENT NAMES**\n- **SEE ALSO**\n- **BUGS**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "POE::NFA",
        "section": "",
        "mode": "perldoc",
        "summary": "POE::NFA - an event-driven state machine (nondeterministic finite automaton)",
        "synopsis": "use POE::Kernel;\nuse POE::NFA;\nuse POE::Wheel::ReadLine;\n# Spawn an NFA and enter its initial state.\nPOE::NFA->spawn(\ninlinestates => {\ninitial => {\nsetup => \\&setupstuff,\n},\nstatelogin => {\nonentry => \\&loginprompt,\noninput => \\&savelogin,\n},\nstatepassword => {\nonentry => \\&passwordprompt,\noninput => \\&checkpassword,\n},\nstatecmd => {\nonentry => \\&commandprompt,\noninput => \\&handlecommand,\n},\n},\n)->gotostate(initial => \"setup\");\nPOE::Kernel->run();\nexit;\nsub setupstuff {\n$[RUNSTATE]{io} = POE::Wheel::ReadLine->new(\nInputEvent => 'oninput',\n);\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\nsub loginprompt { $[RUNSTATE]{io}->get('Login: '); }\nsub savelogin {\n$[RUNSTATE]{login} = $[ARG0];\n$[MACHINE]->gotostate(statepassword => \"onentry\");\n}\nsub passwordprompt { $[RUNSTATE]{io}->get('Password: '); }\nsub checkpassword {\nif ($[RUNSTATE]{login} eq $[ARG0]) {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\nelse {\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\n}\nsub commandprompt { $[RUNSTATE]{io}->get('Cmd: '); }\nsub handlecommand {\n$[RUNSTATE]{io}->put(\"  <<$[ARG0]>>\");\nif ($[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {\n$[RUNSTATE]{io}->put('Bye!');\n$[MACHINE]->stop();\n}\nelse {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\n}",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 66,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 20,
                "subsections": []
            },
            {
                "name": "PUBLIC METHODS",
                "lines": 8,
                "subsections": [
                    {
                        "name": "get_runstate",
                        "lines": 4
                    },
                    {
                        "name": "spawn",
                        "lines": 53
                    },
                    {
                        "name": "goto_state",
                        "lines": 13
                    },
                    {
                        "name": "stop",
                        "lines": 2
                    },
                    {
                        "name": "stop",
                        "lines": 5
                    },
                    {
                        "name": "call_state",
                        "lines": 10
                    },
                    {
                        "name": "return_state",
                        "lines": 5
                    },
                    {
                        "name": "Methods that match POE::Session",
                        "lines": 10
                    }
                ]
            },
            {
                "name": "PREDEFINED EVENT FIELDS",
                "lines": 24,
                "subsections": []
            },
            {
                "name": "PREDEFINED EVENT NAMES",
                "lines": 11,
                "subsections": []
            },
            {
                "name": "SEE ALSO",
                "lines": 5,
                "subsections": []
            },
            {
                "name": "BUGS",
                "lines": 7,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "POE::NFA - an event-driven state machine (nondeterministic finite automaton)\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "use POE::Kernel;\nuse POE::NFA;\nuse POE::Wheel::ReadLine;\n\n# Spawn an NFA and enter its initial state.\nPOE::NFA->spawn(\ninlinestates => {\ninitial => {\nsetup => \\&setupstuff,\n},\nstatelogin => {\nonentry => \\&loginprompt,\noninput => \\&savelogin,\n},\nstatepassword => {\nonentry => \\&passwordprompt,\noninput => \\&checkpassword,\n},\nstatecmd => {\nonentry => \\&commandprompt,\noninput => \\&handlecommand,\n},\n},\n)->gotostate(initial => \"setup\");\n\nPOE::Kernel->run();\nexit;\n\nsub setupstuff {\n$[RUNSTATE]{io} = POE::Wheel::ReadLine->new(\nInputEvent => 'oninput',\n);\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\n\nsub loginprompt { $[RUNSTATE]{io}->get('Login: '); }\n\nsub savelogin {\n$[RUNSTATE]{login} = $[ARG0];\n$[MACHINE]->gotostate(statepassword => \"onentry\");\n}\n\nsub passwordprompt { $[RUNSTATE]{io}->get('Password: '); }\n\nsub checkpassword {\nif ($[RUNSTATE]{login} eq $[ARG0]) {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\nelse {\n$[MACHINE]->gotostate(statelogin => \"onentry\");\n}\n}\n\nsub commandprompt { $[RUNSTATE]{io}->get('Cmd: '); }\n\nsub handlecommand {\n$[RUNSTATE]{io}->put(\"  <<$[ARG0]>>\");\nif ($[ARG0] =~ /^(?:quit|stop|exit|halt|bye)$/i) {\n$[RUNSTATE]{io}->put('Bye!');\n$[MACHINE]->stop();\n}\nelse {\n$[MACHINE]->gotostate(statecmd => \"onentry\");\n}\n}\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "POE::NFA implements a different kind of POE session: A non-deterministic finite automaton. Let's\nbreak that down.\n\nA finite automaton is a state machine with a bounded number of states and transitions.\nTechnically, POE::NFA objects may modify themselves at run time, so they aren't really \"finite\".\nRun-time modification isn't currently supported by the API, so plausible deniability is\nmaintained!\n\nDeterministic state machines are ones where all possible transitions are known at compile time.\nPOE::NFA is \"non-deterministic\" because transitions may change based on run-time conditions.\n\nBut more simply, POE::NFA is like POE::Session but with banks of event handlers that may be\nswapped according to the session's run-time state. Consider the SYNOPSIS example, which has\n\"onentry\" and \"oninput\" handlers that do different things depending on the run-time state.\nPOE::Wheel::ReadLine throws \"oninput\", but different things happen depending whether the\nsession is in its \"login\", \"password\" or \"command\" state.\n\nPOE::NFA borrows heavily from POE::Session, so this document will only discuss the differences.\nPlease see POE::Session for things which are similar.\n",
                "subsections": []
            },
            "PUBLIC METHODS": {
                "content": "This document mainly focuses on the differences from POE::Session.\n\ngetcurrentstate\nEach machine state has a name. getcurrentstate() returns the name of the machine's current\nstate. getcurrentstate() is mainly used to retrieve the state of some other machine. It's\neasier (and faster) to use $[STATE] in a machine's own event handlers.\n\ngetrunstate",
                "subsections": [
                    {
                        "name": "get_runstate",
                        "content": "HEAPs, so this method does pretty much the same as POE::Session's getheap(). It's easier (and\nfaster) to use $[RUNSTATE] in a machine's own event handlers, however.\n\nspawn STATENAME => HANDLERSHASHREF[, ...]"
                    },
                    {
                        "name": "spawn",
                        "content": "spawned like threads or processes rather than instantiated like objects.\n\nThe machine itself is defined as a list of state names and hashes that map events to handlers\nwithin each state.\n\nmy %states = (\nstate1 => {\nevent1 => \\&handler1,\nevent2 => \\&handler2,\n},\nstate2 => {\nevent1 => \\&handler3,\nevent2 => \\&handler4,\n},\n);\n\nA single event may be handled by many states. The proper handler will be called depending on the\nmachine's current state. For example, if \"event1\" is dispatched while the machine is in\n\"state2\", then handler3() will be called to handle the event. The state -> event -> handler\nmap looks like this:\n\n$machine{state2}{event1} = \\&handler3;\n\nInstead of \"inlinestates\", \"objectstates\" or \"packagestates\" may be used. These map the\nevents of a state to an object or package method respectively.\n\nobjectstates => {\nstate1 => [\n$object1 => [qw(event1 event2)],\n],\nstate2 => [\n$object2 => {\nevent1 => method1,\nevent2 => method2,\n}\n]\n}\n\nIn the example above, in the case of \"event1\" coming in while the machine is in \"state1\",\nmethod \"event1\" will be called on $object1. If the machine is in \"state2\", method \"method1\"\nwill be called on $object2.\n\n\"packagestates\" is very similar, but instead of using an $object, you pass in a \"Package::Name\"\n\nThe \"runstate\" parameter allows \"RUNSTATE\" to be initialized differently at instantiation time.\n\"RUNSTATE\", like heaps, are usually anonymous hashrefs, but \"runstate\" may set them to be array\nreferences or even objects.\n\nState transitions are not necessarily executed immediately by default. Rather, they are placed\nin POEs event queue behind any currently pending events. Enabling the \"immediate\" option causes\nstate transitions to occur immediately, regardless of any queued events.\n\ngotostate NEWSTATE[, ENTRYEVENT[, EVENTARGS]]"
                    },
                    {
                        "name": "goto_state",
                        "content": "will be dispatched after the machine enters the new state. EVENTARGS, if included, will be\npassed to the entry event's handler via \"ARG0..$#\".\n\n# Switch to the next state.\n$[MACHINE]->gotostate( 'nextstate' );\n\n# Switch to the next state, and call a specific entry point.\n$[MACHINE]->gotostate( 'nextstate', 'entryevent' );\n\n# Switch to the next state; call an entry point with some values.\n$[MACHINE]->gotostate( 'nextstate', 'entryevent', @parameters );\n\nstop"
                    },
                    {
                        "name": "stop",
                        "content": "to do, just like POE::Session.\n"
                    },
                    {
                        "name": "stop",
                        "content": "in the machine's \"RUNSTATE\" are not POE's responsibility and may cause memory leaks.\n\n$[MACHINE]->stop();\n\ncallstate RETURNEVENT, NEWSTATE[, ENTRYEVENT[, EVENTARGS]]"
                    },
                    {
                        "name": "call_state",
                        "content": "later point, a handler can call returnstate() to pop the call stack and return the machine to\nits old state. At that point, a \"RETURNEVENT\" will be posted to notify the old state of the\nreturn.\n\n$machine->callstate( 'returnhere', 'newstate', 'entryevent' );\n\nAs with gotostate(), \"ENTRYEVENT\" is the event that will be emitted once the machine enters\nits new state. \"ENTRYARGS\" are parameters passed to the \"ENTRYEVENT\" handler via \"ARG0..$#\".\n\nreturnstate [RETURNARGS]"
                    },
                    {
                        "name": "return_state",
                        "content": "preceding callstate() included a return event then its handler will be invoked along with some\noptional \"RETURNARGS\". The \"RETURNARGS\" will be passed to the return handler via \"ARG0..$#\".\n\n$[MACHINE]->returnstate( 'success', @successvalues );\n"
                    },
                    {
                        "name": "Methods that match POE::Session",
                        "content": "The following methods behave identically to the ones in POE::Session.\n\nID\noption\npostback\ncallback\n\nAbout new() and create()\nPOE::NFA's constructor is spawn(), not new() or create().\n"
                    }
                ]
            },
            "PREDEFINED EVENT FIELDS": {
                "content": "POE::NFA's predefined event fields are the same as POE::Session's with the following three\nexceptions.\n\nMACHINE\n\"MACHINE\" is equivalent to Session's \"SESSION\" field. It holds a reference to the current state\nmachine, and is useful for calling its methods.\n\nSee POE::Session's \"SESSION\" field for more information.\n\n$[MACHINE]->gotostate( $nextstate, $nextstateentryevent );\n\nRUNSTATE\n\"RUNSTATE\" is equivalent to Session's \"HEAP\" field. It holds an anonymous hash reference which\nPOE is guaranteed not to touch. Data stored in \"RUNSTATE\" will persist between handler\ninvocations.\n\nSTATE\n\"STATE\" contains the name of the machine's current state. It is not equivalent to anything from\nPOE::Session.\n\nEVENT\n\"EVENT\" is equivalent to Session's \"STATE\" field. It holds the name of the event which invoked\nthe current handler. See POE::Session's \"STATE\" field for more information.\n",
                "subsections": []
            },
            "PREDEFINED EVENT NAMES": {
                "content": "POE::NFA defines four events of its own. These events are used internally and may not be\noverridden by application code.\n\nSee POE::Session's \"PREDEFINED EVENT NAMES\" section for more information about other predefined\nevents.\n\nThe events are: \"poenfagotostate\", \"poenfapushstate\", \"poenfapopstate\", \"poenfastop\".\n\nYes, all the internal events begin with \"poenfa\". More may be forthcoming, but they will\nalways begin the same way. Therefore please do not define events beginning with \"poenfa\".\n",
                "subsections": []
            },
            "SEE ALSO": {
                "content": "Many of POE::NFA's features are taken directly from POE::Session. Please see POE::Session for\nmore information.\n\nThe SEE ALSO section in POE contains a table of contents covering the entire POE distribution.\n",
                "subsections": []
            },
            "BUGS": {
                "content": "See POE::Session's documentation.\n\nPOE::NFA is not as feature-complete as POE::Session. Your feedback is appreciated.\n\nAUTHORS & COPYRIGHTS\nPlease see POE for more information about authors and contributors.\n",
                "subsections": []
            }
        }
    }
}