guinevere-parse/main.cpp

#include <iostream>
#include <string>
using namespace std;

/* Team Kitty, 2019 */
/*   Guinevere One  */

/* This package is the parsing system (NLP) for the Guinevere system.
    This package is split up into 5 different parts, each controlled by
    modules. This is the file that controls all of the other modules,
    making sure that the system reacts the way it was configured.

   It should be mentioned here, before we start, that this system does
    not use advanced Machine Learning systems, or anything automagical.
    It runs entirely on predetermined algorithms, which are fully
    designed manually, so the system is not infallible.

   The system can be configured to run in 3 different ways;
  - As a console application, where it uses stdio to communicate with
    the user, parsing internally. This is ideal for command-line usage,
    and was designed purely for testing the system. This is not the
    intended usage.
  - As a web server. In this configuration, it starts a web server on a
    configurable port and listens for incoming connections. This is the
    intended usage of the Guinevere parsing system, as it can then send
    out commands to other devices.
  - As a web client. In this configuration it listens for input over
    stdin and sends it out to the listen server. This makes developing
    the main clients considerably faster.
        Maybe implement this into the Guinevere main clients eventually?

   Currently, the program has 5 sections, as mentioned above:
  - Input; this is where the 3 modes mentioned above are implemented
  - Parsing; this is only done if the console app configuration is
    chosen above. Otherwise, it skips this module.
  - Evaluation; this is only done in debug mode, in console app
    configuration. It tries to prepare an output that tells the user how
    likely it was to pick each module for the given input.
  - Knowledge; if the output was strange, and if "Define" was the most
    likely module in Evaluation, it can save time by enabling the
    Knowledge system to attempt to get a definition of the "Define"
    keyword from Wolfram|Alpha. Since this cuts down the rate of network
    access by half, it might improve data usage.
  - Output; finally, once all of the sections have yielded, it tries
    to output the requested data in a decent format. If the system is
    running as a console app, it outputs to STDOUT. If the system is
    running as a web server, it sends a nicely formatted JSON
    encoded package to the connected client, or displays said package if
    running as the client.

   The Parsing and Knowledge systems connect to various Modules:
  - Identify: Triggered by "What is", "Who is" and "How do I" questions.
    It tries to pull a short definition from WikiTL;DR, or redirects to
    the most appropriate Wiki page if that fails. If the user complains,
    saying "That wasn't useful", or "Try again", it tries to reach out
    to Plowie or W|A to get an answer there. If Identify doesn't work,
    it falls through to the next appropriate module.
        This is the module expected to be used the most, so it will have
        the most time put into it.
  - Control: Triggered by "Set", "Play" or other commands that are
    deemed to be likely to control or change the state of something.
    The Guinevere system was originally designed to be used with
    custom Smart Home electronics and systems, so this will probably
    be the second most developed system. It will have subsystems for
    changing the color and intensity of smart lighting, as well as
    systems for controlling custom Smart Locks eventually.
    This will not be forseeable for quite a while, though.
  - System Control: A subsystem of Control, but important enough to
    require an explanation nonetheless. If Guinevere is eventually
    integrated within Sync, this module will allow voice control of many
    internal components of the system. With a builtin passcode, it can
    also be used to control kernel level things, like multitasking
    methods and paging control systems. In user-land, it can also be
    used for dictation input (if you trust my algorithms enough)
    or for changing user settings, such as keyboard layout, hotkey
    behaviour, or window manager/compositor settings.
        Perhaps this interface could eventually be used as an
        optional replacement for configuration files?
  - Define: The fallthrough. If the user says a random word, which is
    not identified as a custom keyword, then the system will ping W|A to
    get a nicely formatted definition of that word.
*/

// First is the definition of the common types:
/* There are three main classes used in the processing of requests:
  - First, there is the input. The input is returned by the input
    detection system, and is used in Processing for determining the
    Intent.
  - Second, there is the Intent itself. The Intent is a construction
    of how likely the input command is to belong to a module. Since
    the Intent algorithm is an algorithm and not a Machine Learning/
    Neural Network thing, it can be easily changed and tweaked to match
    the correct criteria. Out of the Processing system, the intent is
    used to trigger the correct module and the Intent is then discarded.
  - The output is a structure which is given from Processing to Output,
    and is used to generate a nicely formatted output. The output itself
    is sent around inside the program as a JSON/XML string. I have yet
    to decide.
*/


int main() {
    

    return 0;
}