The basic idea behind these substantial changes in the language specifications is that Markle wishes that this development environment be broadly accessible. Moreover, Dave and I, in contemplating the issues in detail, have come up with a variety of corrections to previous clumsy ideas.
The biggest idea &emdash; and I must give Dave full credit for this stroke of genius &emdash; is to use a point-and-click editor rather than a text editor. (And Dave's the PC guy and I'm the Mac guy: I hang my head in shame.) Every single element of the language will be directly accessible from menus, dialog boxes, or icon bars. The storybuilder will assemble the components of a verb record from these listings. He will not type in abstruse text commands that must then be parsed (with errors likely) and converted into a machine-readable format. This is not only easier on the storybuilder, it's easier on the computer, as we have no intermediate compilation. Unfortunately, it makes the design and development process less modular; I had originally planned that the language would be attacked in Stage II. This concept requires that the language be integrated into the editor. This makes the scheduling issue more complicated.
There are a couple of places where the storybuilder will type in data. First, whenever he creates a new verb with the "New Verb" menu item, the very first thing he will face will be a dialog box demanding the label for the new verb, a string of characters (including spaces) up to 32 characters in length. The 32-character limit is made necessary by the need to present verb labels in the scrolling list boxes. Second, the storybuilder can type numerals &emdash; and only numerals! &emdash; when entering a term for the expression editor.
To understand the changes, I must first describe a major new concept that underlies many of the changes: the role. A role is a state occupied by zero or more persons in relation to a particular substory. Some examples will make this definition more palatable. Let's take the simple case in which Subject punches DirObject. In this case, Subject plays the role of "puncher" and DirObject plays the role of "punchee". You might well ask, if that's all there is to the concept, why bother with roles? Why not simply talk about Subjects and DirObjects? Well, that's because there might be other roles as well. We might have a "witness" role, applied to anybody in the same room who observes Subject punching DirObject. Or perhaps we might have a "deferred witness" role, applied to anybody who is not present but later learns about Subject punching DirObject.
The significance of roles is that each role has a number of consequences associated with it. Punchee might respond to the punch one way, but a witness would have a different set of possible responses, and a deferred witness would have still other possibilities. In my current hand-coded implementation, roles are implicit but tangled together in a mass of custom-coding; I intend to formalize the construct in the editor to make it easier for non-programmers to understand.
Mind you, roles can get pretty complicated. How about the role of "aggrieved lover", who finds out that somebody's been stepping out on him/her? Or what about "irritated invitee", a lady who's been pestered by a suitor? In this latter case, the definition of the role is dependent upon past history.
Thus, before the storybuilder can define the consequences, s/he must define the roles with a formal boolean specification, using global variable values to determine exactly whether a given character fits this role.
The editor will provide a menu item that permits the storybuilder to create a "New Role" for the verb in question. When this menu item is selected, the storybuilder will be presented with a dialog box that asks for a short 32-character label for the role. That done, the role will be entered into a list of roles presented in a scrolling list box. It will have as its initial definition the default value of "FALSE". At any time, however, the storybuilder can click on this entry in the role list to edit the definition of the role with our point-and-click editor (more on this later).
Once the role has been defined, the next task is to assign consequences to it. This is done with the previously-specified system. As each consequence is assigned, a weighting equation will be figured using the point-and-click editor.
The task of this editor is to build expressions (boolean or arithmetic) out of global variables, basic operators, and custom functions.
Global variables are selected from a hierarchical menu structure that reflects the structs of the global variables. We may need to break a few of the longer structs down even further. For example, the personality struct has 41 members to it; we'd do well to break that up into four chunks. After all, we want to avoid an oversquare menu layout. Arrays will be handled by adding square brackets [] and a default expression for the array-index.
There aren't that many basic operators: multiply, divide, add, subtract, and, or, exclusive-or, and the logical comparisons (>, <, =, !=, <=, >=). Perhaps we can use an icon bar for these.
Custom functions will have to be brought up in a dialog box, if only because we need to define the function and its arguments when the storybuilder considers it. When the storybuilder selects a custom function, it will have default values of FALSE and 0 entered for all of its arguments; the storybuilder can then replace these default values with correct values using the other parts of the editor.
Some of the expressions that the storybuilder will want to build might become rather complex. Accordingly, we want to offer the storybuilder the option to use some local variables. My idea for this is to have a menu called "Insert Local Variable", with menu items called "x", "y", "z" and so forth. Using such a menu item puts that local variable in the selected location, one that would normally take a global variable. It also inserts a line at the end of the expression that says, "Where x = 0". The storybuilder can then go back and edit the expression.To prevent circular definitions, we will require that the first local variable always be "x". Once that variable has been assigned, then "y" can be assigned, then "z", then "a", and so forth. Then the rule enforced by the editor is that, when editing the definition of a local variable, you can't enter the value of a variable equal to or higher than it in the local variable sequence. Thus, x can be defined in terms of y and z, but y can't be defined in terms of x, and z can't be defined in terms of x or y. This prevents circular definitions. We'll deal with other forms of error checking in Stage II.
Each element (variable, operator, or function label) in an expression is treated as a unit; clicking on that element selects it and highlights it. A storybuilder can do one of three things with a selected element: replace it with an element of appropriate type, expand it, or collapse it with the Delete key.
Replacement is done by simply choosing the desired item from the appropriate source. There are three sources: the menus of global variables, the function dialog box, and the operator icon bar. Terms (variables or functions) can only be replaced by terms, and operators can only be replaced by operators.
Expanding an element is done by double-clicking on the element. Expanding an element encloses it inside a pair of parentheses, adds the undefined operator "?", and a second term, also undefined. Expanding an operator treats the dyadic expression created by the operator as a single term and expands it. Thus, if you double-click on the "+" sign in the expression "(a + b)", then you'll get a new expression "((a + b) ? ?)".
Collapsing a term deletes it and the operator with which it is associated, leaving untouched the term that was on the other side of the operator. An operator cannot be collapsed.
To make it easier to access the single-character operators with the mouse, we will use oversize characters for such elements.
One of the clever features of this design (if I do say so myself) is that it allows the storybuilder to leave undefined elements in place. In many cases we can default to a safe value such as zero or FALSE, but in other cases, we insert something that is declared to be undefined. The editor can keep track of this, remembering that there's supposed to be something there, but the storybuilder hasn't gotten to it yet. The editor can issue gentle reminders ("You snivelling fool!! You have FAILED to declare your undefined elements!!! You die at dawn!") at appropriate times.
The idea here is to impose a set of formalisms on the storybuilder that make his job easier to understand. He won't have the freedom to write anything he wants, and the multiple parentheses idea will sometimes make matters clumsy, but it also makes it easier to protect him from his mistakes. This editor isn't foolproof, but it'll take a lot of creative stupidity to screw it up.
There will be 32 flags associated with each verb, which will characterize the nature of the verb. Later on, we might expand this to 64 flags; there's no reason why we have to limit ourselves. Typical flags might be "battle", "romance", "dealmaking", "nasty", "nice", "verbal", "action", and so forth. Each verb will need its flags specified. The flags can then be used for network navigation. You can ask the computer to show you all the verbs with identical flag settings. You could also ask for all the verbs whose flags deviate by just one value, or two. This would allow a different kind of navigation in the network.
There are lots of wonderful ideas that have emerged in the last week, but there's also far too much to do by October 27th. My next task is to organize all this into a workable schedule.