Kahina for QType Tutorial Part 4: Control Agents

This tutorial only assumes that you know how to compile grammars and trace parsing processes in Kahina for QType. The most direct way to acquire this knowledge is to work through the tutorials QTypeTutorial1 and QTypeTutorial2. In this tutorial, you will start to gather some experience with the use of control agents, which is Kahina's powerful mechanism for automatizing tracing processes and defining helpful system behavior. However, you will not yet learn how to specify control agents. Instead, we will focus on exploring how the control agent system works with the help of a predefined control agent profile.

Loading the Tutorial Project

This control agent profile is defined together with a slightly altered window layout in a project which will be used for this and the next tutorial. To proceed with this tutorial, open the submenu under Project -> Open Project -> Predefined Projects and select the entry QType Tutorial 4-5. As usual, this will cause the GUI to be rebuilt with a slightly different layout.

You might notice that a new view component has appeared. Before you can start to learn about its significance, you will need to compile the grammar as usual, that is, by clicking the Grammar -> Compile menu entry and skipping over the compile_grammar/1 step which appears. When the compilation has finished, your Kahina window should look roughly like this:

Starting a Predefined Example Parse

So far, we have always started our parses via the Grammar -> Parse ... dialogue. As you might have noticed, there is also a submenu Grammar -> Parse example which lets you select from a list of parses. These listed sentences are retreived from QType during the grammar compilation process, and they exactly correspond to the test sentences specified in the respective grammar. In future versions of Kahina, it will be possible to define additional example sentences as part of a project file, but for now the only mechanism to add example sentences is by editing the grammar file.

The list of sentences that comes with our example grammar contains many interesting examples. For explaining the control agent system, we will again restrict ourselves to a very simple test case. To proceed, start the parse of uther sleeps by clicking on the menu entry Grammar -> Parse example -> uther sleeps.

The Control Agent Profile

A tracing control agent in Kahina is best seen as a simple autonomous agent consisting of a sensor which can detect patterns in individual steps or in the step tree, and an actuator which can react to pattern matches in the sensor by issuing tracing commands. The terminology is borrowed from the field of artificial intelligence with a reason, since control agents are a method of describing and implementing intelligent behavior with the purpose of automatizing parts of the tracing and thereby of the grammar debugging process.

According to the tracing command it issues, a control agent will often simply be called a creep agent, a skip agent etc. For convenience, control agents which issue the same tracing command are commonly grouped together in control agent profiles. Individual control agents as well as control agent profiles can be stored and loaded within or separately of projects. In later tutorials, you will learn how to define simple control agents and how to administer control agent profiles, whereas in this tutorial, you will only see some pre-defined examples of what control agents can be made to do.

Together with the tutorial project, a useful set of control agent profiles for the purposes of QType debugging has already been loaded. These control agents have quite some impact on the behavior and especially on the speed of tracing processes. We will now discuss these changes and their advantages while going through the trace of uther sleeps, while also discussing from a more general perspective the typical usage scenarios of the occurring agent types.

Observing the Behavior of a Complete Agent

Turning to the new view component, we see that it contains a tab for each tracing command. These control agent profile editors will later become the place where you administer the various control agents, but for now, we will only use the editors to take a look at the predefined agents that came with the project. If you switch to the Complete tab, you will see a list of complete agents, with only one entry named "complete lexentry". When you select an agent from this list, you will see a representation of that agent's sensor on the right of the profile editor window. The pattern box says that this complete agent is listening for steps whose label contains the string lexentry_existence.

We see the consequences of this complete point being active when we start creeping into the trace. After the second creep, we will suddenly see three new steps in the overview tree, all of which are colored in green. As you will have guessed, this is exactly what would have happened if you had issued the auto-complete command after the last creep operation. The sensor of the "complete lexentry" agent has detected that the new step is a call to the predicate lexentry_existence/2, causing the actuator to fire and an auto-complete command to be issued:

You will soon see that this type of control automation makes tracing a lot faster, because simple criteria can be used to automatize stereotypical tracing actions. A grammar engineer will simply always want to skip or auto-complete any lexentry_existence/2 calls, and the control agent system gives him or her the possibility to automate this action, doing away with some of the strain of always paying close attention to avoid mistakes, and minimizing consideration time.

Observing the Behavior of a Skip Agent

The other agent types work in a manner analogous to complete agents. The next step is a call to mgu/2, which matches the pattern detected by the sensor of the skip agent of name "skip mgu", causing its actuator to issue a skip command. Looking at the Skip tab of the control agent profile editor, we see that skip agents are defined for step labels containing the strings "mgu" and "unify". This reflects the fact that a grammar implementor will generally not be interested in the inner workings of QType's feature logic engine, making it unnecessary to wait for the slow transmission of these step details from QType to Kahina.

To make the occurring trace commands and their causes more transparent, the console displays an additional message whenever some non-creep command was issued, complete with the step at which it occurred, and the name of the agent. In the case where it was the user who issued the non-creep command, the agent string "User" is used. Note that for the automated skip we just witnessed, two messages show up in the console. The first one informs us that a skip command was successfully issued when the mgu/2 step was called, and the second one informs us that the sensor of the skip point matched again when we entered the step's exit port. However, since skip operations are not allowed at exit ports, the message merely contains a warning saying that the actuator failed to issue its command.

Observing the Behavior of a Creep Agent

The reason why sensors are not only allowed to match at call ports becomes clear when we encounter the match of a creep agent. As you will find out by inspecting the control agents listed in the Creep tab of the control agent profile editor, there are two pre-defined creep agents. The first one is listening for steps with labels containing "db_word", and the second one issues a creep command whenever it sees a step with label "db_rule". The latter creep agent becomes active as soon as we descend into the top-level call to lc/6:

On the message console, you can see that the creep agent has in fact issued a creep command twice, because its sensor matched once at the call port and again at the exit port. For steps which do not require any subgoals to be called, a creep agent will therefore cause the trace to "jump over" any matching call. This mechanism is used in the default control agent profile to automatically pass by any queries to the lexicon or the rule database even in creep mode.

Now that we have discussed the behavior of all the control agents defined in the present tutorial project, the user should feel free to creep through the entire parse, getting a feeling for how these three simple control agent profiles together amount to an entirely different user experience while tracing. For sake of comparison, you can revert to QTypeTutorial2 in order to remind yourself how slow tracing was without the aid of control agents.

Activating and Deactivating Agents

There might be situations where at some point during the trace, you decide that you need to see the details skipped over by a skip agent, or that you want to pause and think at every invocation of a goal which a creep agent listens for. For such purposes, it is possible to deactivate and reactivate control agents at any point during a trace. This is done via the context menu which pops up when you right-click on one of the agents listed in the control agent profile editor:

Deactivated control agents are marked by a hash sign in front of their name in the list. As long as the control agent is inactive, tracing will behave just as if the control agent were not present at all. You can also reactivate an inactive control agent at any point using the same popup menu.

Further Steps

While fail agents and warn agents are seldom-used mechanisms which we will not cover in the tutorials, we have so far failed to cover the very important topic of Break Agents. This type of agents makes it possible to emulate the behavior of Prolog-side breakpoints, making the Leap operation much more useful than before. Aside from the use of break agents, we will also learn how to define a very simple kind of control agent in QTypeTutorial5. QTypeTutorial6 then explains how to make full use of the control agent system by defining and assembling new control agent profiles, making it possible to further customize Kahina's behavior.