How Texai Writes Its Own Programs
Texai writes its own Java programs by having an essential set of primitive capabilities that step-by-step can compose Java classes. Each primitive capability has these characteristics:
- preconditions - the set of semantic formulas that must subsume the corresponding precondition formulas in the commanded task
- input-roles - the set of variables that are input to the capability
- output-roles - the set of variables that are populated by the capability
- postconditions - the set of semantic formulas that must be subsumed by the corresponding postconditions in the commanded task
- invariant conditions - the set of implication formulas that satisfy the corresponding invariant conditions in the commanded task
- emit - the ability to emit (i.e. generate) a particular Java source code element or composed element
For example here is a primitive capability for declaring an instance variable in a Java class:
(capability
name: “defineInstanceVariable”
description: “Defines an instance variable having the given name and object type.”
preconditions:
(<rdf:type> ?variable-name <texai:JavaVariableName_NonEmptyCharacterString>)
(<rdf:type> ?object-type <texai:JavaType_CharacterString>)
(<rdf:type> ?variable-comment <texai:JavaComment_CharacterString>)
(<rdf:type> ?variable-invariant-conditions <texai:JavaInvariantConditions_Tuple>)
(implies
(<cyc:memberOfTuple> ?variable-invariant-condition ?variable-invariant-conditions)
(<rdf:type> ?variable-invariant-condition <cyc:CycLFormula>))
input-roles:
(<texai:blRole> ?variable-name “a variable name”)
(<texai:blRole> ?object-type “a type”)
(<texai:blRole> ?variable-comment “a comment”)
(<texai:blRole> ?variable-invariant-conditions “some invariant conditions”)
output-roles:
(<texai:blRole> ?defined-instance-variable “the defined instance variable”)
postconditions:
(<rdf:type> ?defined-instance-variable <texai:org.texai.bl.domainEntity.BLInstanceVariable>)
(<texai:blInstanceVariableName> ?defined-instance-variable ?variable-name)
(<texai:blInstanceVariableType> ?defined-instance-variable ?object-type)
(implies
(<cyc:memberOfTuple> ?variable-invariant-condition ?variable-invariant-conditions)
(<texai:blInstanceVariableInvariantCondition> ?defined-instance-variable ?variable-invariant-condition))
)
Here is a sample task that matches the above capability:
(task
preconditions:
(<rdf:type> <texai:JavaObject_AVariableName> <texai:JavaVariableName_NonEmptyCharacterString>)
(<rdf:type> <texai:JavaObject_AType> <texai:JavaType_CharacterString>)
(<rdf:type> <texai:JavaObject_AComment> <texai:JavaComment_CharacterString>)
(<rdf:type> <texai:JavaObject_SomeInvariantConditions> <texai:JavaInvariantConditions_Tuple>)
(implies
(<cyc:memberOfTuple> ?variable-invariant-condition <texai:JavaObject_SomeInvariantConditions>)
(<rdf:type> ?variable-invariant-condition <cyc:CycLFormula>))
postconditions:
(<rdf:type> ?defined-instance-variable <texai:org.texai.bl.domainEntity.BLInstanceVariable>)
(<texai:blInstanceVariableName> ?defined-instance-variable ?variable-name)
(<texai:blInstanceVariableType> ?defined-instance-variable ?object-type)
(<texai:blInstanceVariableComment> ?defined-instance-variable ?variable-comment)
(implies
(<cyc:memberOfTuple> ?variable-invariant-condition <texai:JavaObject_SomeInvariantConditions>)
(<texai:blInstanceVariableInvariantCondition> ?defined-instance-variable ?variable-invariant-condition))
)
Here are the Java objects that are bound to the task JavaObject terms:
- texai:JavaObject_AVariableName <–> “testFloat”
- texai:JavaObject_AType <–> “float”
- texai:JavaObject_AComment <–> “a test float”
After the defineInstanceVariable capability executes, it creates a BLInstanceVariable Java object that can emit the following Java source code:
/** a test float */
float testFloat;
At this point, only the most primitive composition capabilities are defined. I’ll hand-code English dialog routines that invoke these. Then I hope that Texai can acquire skills and build more complex programs via English dialog.
David Whitten on 24 Jun 2008 at 5:37 am #
I’m wondering if you need to tease out just a little more detail.
Right now, I view your java objects as a “capability” more than an “action”. I expect that you are right now, simply combining the idea of being able to do something with the action of doing something. In some systems, I’ve seen this teased apart into a definition, a capability, and the application of that capability to some specific inputs. Related to this view, I’m happy to see you are talking about input-roles and output-roles, rather than simply inputs and outputs. So the application of an expression that invokes these capabilities is still not a part of this page.
In some ways, your capabilites definition here can be seen as setting up the qualifications of a bus-driver to drive a bus, but not actually dealing with the occurrence of a particular bus-driving event. What kinds of distinctions are necessary to deal with the java object when it is actually used?
omadeon on 18 Jul 2008 at 9:13 pm #
Mr. Reed, I’ ve been reading your impressive (and educationally very valuable) posts, a long time now. This time, however, I tend to believe you seem to follow a somewhat extreme “purism”, wanting java programs to… write their own java code. Surely such meta-level programming could be done more elegantly in Prolog or in Haskell, and then linked to lower-level languages if necessary.
David Whitten on 20 Aug 2008 at 6:30 am #
I beg to differ with Omadeon. I can see great utility in generating Java programs. Strictly speaking, I know this Texai behavior language is written in Java, but I don’t think Steve is advocating Java for that reason. My opinion about the advantage in generating Java is that Steve is a great Java programmer. Whatever language you are spending most of your time working within, you can see the ways to “naturally” code things. If Steve spends all his time learning Haskell or Prolog, he will spend no time creating the Texai Behaviour Language, and end up no closer to his goal. Focus is incredibly important in this kind of endeavor.