Recursive Sentence Structures

The time has come to tackle one of the most difficult problems I face: recursive sentence structures. Storytron technology uses a fixed sentence structure in which each sentence contains up to 16 word sockets, of which the first two are the Subject and the Verb; the remainder are defined by the Verb. This structure cannot handle Verbs that take clauses as objects. A simple example:


Fred told John that Mary gave Fred the hamburger.
Fred told John that Mary hates John.

In the first sentence, the secondary clause contains four words; in the second sentence, it contains three words. The fundamental solution is obvious: a verb must be able to take a clause in a word socket, and that clause can contain a verb with its own set of word sockets.

In terms of data structures, this is not a difficult problem. I don’t even need to add a new element to those that can be contained in a word socket. I need only change the sentence structure so that every verb adds its own structure to the sentence. Thus, the sentence is built by adding the verb as an object, then adding the word sockets assigned to that verb. Here’s how the sentence structures would be built for the first two sentences:

Fred tell John give Mary Fred hamburger.
Fred tell John hate Mary John

An interesting aside: there are a number of word orders used by various languages. The most common is SVO: subject followed by verb followed by object. (“I sense the dark side”) A close second in popularity is SOV: subject followed by object followed by verb. (I the dark side sense”) There are also a few VSO languages. (Sense I the dark side”) Yoda uses the rare OSV word order (“The dark side I sense”). For our purposes, the VSO word order is the obvious choice, because the verb defines the word order; you’ve to to specify the verb before you know what other word sockets must be filled.

There’s a counterargument to this: every clause MUST have a subject. Accordingly, we could specify the subject before the verb because we KNOW that the verb will have a subject. The clinching argument is this: specifying the subject before the verb places additional limits on the number of potential verbs in the sentence. Usually there will be but a few possible subjects, but there can sometimes be a huge set of possible verbs, so anything I do to reduce that verb set will improve the user interface.

Oops, I just realized a counter-counterargument arising from the geometry of SympolTalk. Consider the following sentence:

asdfsadfasdf

Suppose that the user has entered the first three words (“Chris tell Darth Maul…”). Now Chris must enter the fourth word. If he enters the subject of the clause, then that entry will be hanging without a connection. We’ll get something looking like this:

This looks clumsy to me. I think that this would look better:



Still, I suppose that the first arrangement is more serviceable.

Overactive verbs
I expect some nasty surprises to arise with particular verbs. Consider, as an example, the verb ‘ask’. It can take a verb as an indirect object (“Chris ask Darth did Darth kill CockRobin”) or an actor (“Chris ask Darth who killed CockRobin”) or an intensifier ((“Chris ask Darth how many good auras Donald Duck has.”)

One solution is to break up the ask verb into subordinate forms: ask who, ask what, ask how many. But can these be presented as meaningful icons? Here’s a stab at it:

Hmm… I don’t know. Perhaps.

Layout Issues
A third problem concerns the problem of laying out the sentence as it is being built. The great majority of clause structures can be built using fairly simple algorithms: Subject on the left, verb in the middle, dirobject on the right, with another object below. But what happens when clauses collide? Here’s a nasty example:




Oh sure, I was able to lay it out neatly, and I could specify that the deal verb takes its two object-verbs underneath the two actors, but what happens when I hit those object-verbs? Does the layout algorithm follow the rules and lay them out according to the standard SVO layout? If so, the two clauses collide. This layout is very much a special-case situation. I certainly can’t special-case the code, because the verb-objects could be different as in “Mad Scientist offers to give bicycle to Wile E. Coyote if he tells Mad Scientist the number of power auras that Donald Duck has.”

Optional modifiersCould a situation ever arise in which the player might or might not want to enter a modifier? For example, consider the inversion modifier. What happens when the user faces the option:


“Wile E. Coyote tells Mad Scientist that his dream-battles last night went very badly.”

What happens at the very end of that sentence? The user has just entered the 6-value intensifier. We present him with a menu consisting of the inversion modifier and –what? Nothing? How do we show nothing? An empty modifier? Hmm, that might work.