OpenCogPrime:CombinatorsAndProcedureNodes
Combinators And Procedure Nodes
From Combinators to ProcedureNodes
How are Combinators actually used in OCP?
The basic principles are as follows:
- OCP Atoms, besides SchemaNodes, are treated as constants that can be acted on by schema
- We introduce a set of elementary schema, including arithmetic and logical operators, and also schema that take actions in the outside world (like sending out a character of text or moving an actuator) and schema that monitor the overall state of the system. The full elementary schema set will be presented in the following Chapter.
- We use the standard combinators {S, K, I, B , C } as defined above to build up complex expressions from the given constants and elementary schema.
This is not unlike how combinatory logic is used to build up functional programming languages.
The class
ComboTree
is then used to refer to the combinator expressions built up from the elementary schema and constants in OCP; and the class
Predicate in ComboTree
refers to those schema that output TruthValue objects.
SchemaNodes are so named because the mapping
Schema-Valuator in [ Atom --> ComboTree ]
associates them with Procedures. Similarly, for PredicateNodes, we have a mapping
PredicateValuator in [ Atom --> Predicate ]
The set of elementary Schemata and Predicates will be the same for a certain OCP system at all points in time -- unless one has a OCP system that is modifying its own codebase. Otherwise, new schema and predicate expressions will be created, but using the same basic hard-wired vocabulary. Of course, the given vocabulary of elementary schemata has universal computational power; but even so, it is quite possible that enhancements to the set of elementary schema could make the system more intelligent in certain contexts.
Variables and Combinators in OCP
Originally, in an early version of the NCE system (which was OCP's inspiration), there was a design intention to eschew variables entirely in procedures and predicates, and exclusively use variable-free combinator expressions to represent complex functions. In spite of innovations like Turner combinators, however, this eventually came to seem unwise due to the computational complexity of expressing certain intuitively simple functions in a variable-free way. So in the current OCP design, the intention is for ComboTrees to be able to utilize both variables and higher-order combinators, thus achieving the same kind of flexibility that exists in modern functional programming languages (which use director strings and other variable-like formalisms to work around the practical limitations of the pure-combinator approach).
Varieties of Schemata
A list of the various specific elementary schema currently used in OCP will be given later on. Here, as a preliminary, we make some general comments about the kinds of schema in the system.
The main type of schema associated with SchemaNodes is the atom-transforming schema,
Atom-Transforming-Schema in [Atom --> Atom]
The basic combinators (S, K, etc.) fall into this category, for instance, as do Boolean schemata like AND and OR. They are embodied in elementary schema nodes, hence they themselves are represented by Atoms; so their actions on each other may be represented as actions of Atoms on Atoms.
Similarly, PredicateNodes are commonly associated with predicates of the form
Atom-Based-Predicate in [Atom --> TruthValue]
But there are other schema varieties as well; for instance,
Feeling-Predicate in [ AtomSpace --> Truth-Value ]
There are two types of schemata which must be conceived of as special kinds of CIM-Dynamics:
Atom-Deleting-Schema in CIM-Dynamic Atom-Creating-Schema in CIM-Dynamic
An atom deleting schema takes an AtomSpace and removes a particular Atom from it. An atom creating schema takes an AtomSpace and puts a particular atom in it.
Atom-creating and atom-deleting schemas are elements of
[[[AtomSpace]] --> AtomSpace]
Where A and B are two AtomSpaces, an atom-creating schema f has the property
f A = B implies (A subset B)
whereas an atom-deleting schema f has the property
f A = B implies (B subset A)
In the case of multipart or caching AtomSpaces, to be introduced later, there may be atom creation schema that specifically place schemata in particular regions of the AtomSpace.
Altogether, these are the only kinds of schema in the current OCP system, so we may say formally that
Combo tree = Atom-Transforming-Schema Union Atom-Deleting-Schema Union Atom-Creating-Schema Union
Predicate
and
Predicate = Atom-Based-Predicate Union Feeling-Predicate
The elementary schema in any given OCP may be thought of as a ìschema vocabularyî; and we may say that OCP is supplied with a set of ìschema sub-vocabularies,î consisting of schema carrying out particular sorts of purposes. These sub-vocabularies may be defined as sets
Atom-Transforming-Schema-Vocabulary Atom-Creating-Schema-Vocabulary Atom-Deleting-Schema-Vocabulary Predicate-Vocabulary Truth-Value-Schema-Vocabulary Feeling-Vocabulary
We may then define an overall schema vocabulary as:
Schema-Vocabulary = Atom-Transforming-Schema-Vocabulary Union Atom-Deleting-Schema-Vocabulary Union Atom-Creating-Schema-Vocabulary Union Feeling-Vocabulary Union Atom-Based-Predicate-Vocabulary
In general, each OCP is associated with a particular schema vocabulary.
On the implementation level, SchemaNodes and PredicateNodes are associated with combinator expressions formed from the schemata in the systemís schema vocabulary, taking the Atoms in the system as arguments. The combinator expression corresponding to a Node is encapsulated in an object called a ComboTree, which is contained in a structure called the ProcedureRepository (in which a ComboTree is indexed according to the Node that corresponds to it); more details on this will be given in a later chapter.
