# 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.