In the CODIL interpreters information about the tasks being executed is mapped from the CODIL text onto a table which represent a map of a recursive network where each node in the network represents a set or a partition of a set. To keep the human interface the syntax is a simple as possible and it is not concerned about the conventional distinction between "program" and "data".
CODIL is best understood in similar way to a symbolic assembly language designed to work on a recursive network. A conventional symbolic language consists of simple lists of commands mapped onto successive cells in an array. However each command has a syntax structure which includes an explicit instruction and control and/or address information.
CODIL also consists of simple lists of "items" mapped onto a network. In the same way that conventional symbolic language commands have a structure (representing at least an instruction and address) each CODIL item has a syntax structure to represents the partition of a named set. Thus, apart from the internal structure of a CODIL item, a CODIL statement is just an ordered list of items, a CODIL file is just an ordered list of statements, and a CODIL knowledge base is just an ordered list of files.
Seen as a linear text file CODIL has a very simple list based syntax, without any brackets!!!!) and because there is no syntax distinction between "program" and "data" the language does not even contain an explicit word for "IF." This may seem ridiculous to anyone who takes the stored program model mapping onto an array for granted, but explicit "IF"s become redundant when the task is mapped onto a suitably structured recursive network and processed with a human-like decision making unit - which dynamically decides which gateways in the network need to be opened in order to make a useful decision. [In effect this point demonstrates why the algorithmic stored program computer model is a bad model of how the human brain actually works.]
A simple CODIL Item
MURDERER = Macbeth
A CODIL item defines a set, or a partition of a set, and represents a nobe in a network. As seen by the user it consists of the following parts:
- The name of a set - and the set name MURDERER is held in a lexicon. If used on its own as MURDERER it represents the whole set.
- A "demon" which defines how the partition of the set is to be selected or processed. In many case the demon is held between brackets.
- An optional "item value" (test string or number) relating to the selection of the partition.
All CODIL items are held as nodes in the network, typically as part of a CODIL statement in a CODIL set.
A Simple CODIL Statement
MURDERER = Macbeth; VICTIM = Duncan; WEAPON = dagger.
The set names of each item are chosen to define the relevant context and in this context it would be inappropriate to describe Macbeth as member of the sets MALE, MARRIED, or KING (he only became KING after the event) rather that as MURDERER - which fit the context. However elsewhere these set name could be used to describe him.
A statement, when written on one line, is a list of CODIL items, case separated by ";" and terminated with a full stop. However to help reveal the structure to the human user when mapped in the network the individual items are given a level number and the default output format is:
1 MURDERER Macbeth,
2 VICTIM = Duncan,
3 WEAPON = dagger.
Each statement represents an object or an event and is a node in the network - but does not have a individual node name if it is part of a larger CODIL file/set. The numbering represent how deep the item is in the network and is particularly helpful when the CODIL system tells the human user the path it is taking through the network. See TANTALIZER 226.
A CODIL File/Set
A CODIL file is set which contains a named list of statements (In this case say SHAKESPEAREAN CRIMES) and the level number is used to remove duplication and highlight the commonality between adjacent statements.
1 WEAPON = dagger,
2 VICTIM = Duncan,
3 MURDERER = Macbeth.
2 VICTIM = Julius Caesar,
3 MURDERER = Brutus.
In some versions of the CODIL interpreters this statement compression can be taken further by holding multiple statement as a network. For instance in TANTALIZER 226 details of all the possible girls could be recorded in the file/set SCHOOLGIRLSas:
1 HAT = Orange,
1 HAT = Khaki,
1 HAT = Turquoise,
1 HAT = Pink,
2 SCARF = Turquoise,
2 SCARF = Orange,
2 SCARF = Khaki,
2 SCARF = Pink,
3 EMBLEM = Orange,
3 EMBLEM = Pink,
3 EMBLEM = Turquoise,
3 EMBLEM = Khaki,
4 DAUGHTER = Alice,
4 DAUGHTER = Bess,
4 DAUGHTER = Claire,
4 DAUGHTER = Debbie,
5 SCHOOL = St Gertrude.
5 SCHOOL = St Etheldreda.
5 SCHOOL = St Faith.
5 SCHOOL = St Ida.
The Role of Demons
The role of the demon is to define the way the named set is processed, and covers the simple selection of a subset to asking the human user for help. All the demons described here are generic, but it is possible , in the later interpreters, to allow information exchange with non-CODIL software. Below examples are given of some of the demons to illustrate their function and a full lisy is in the MicroCODIL manual
In MURDERER = Macbeth the demon "=" defines Macbeth as a member of the set MURDERER. In an item such as QUANTITY < 100 the partition selected logically contains all numeric values in the set QUANTITY less than 100.
The demon "IS" can be used when the item refers to a partition of a set that needs to be evaluated at the time as in
TOTAL PRICE IS = UNITPRICE * QUANTITY
where UNITPRICE and QUANTITY are named sets.
Because CODIL is designed to handle complex tasks where there could be uncertainty, it is important to handle fuzzy logic. All sets and items have a default (not shown) demon set to 1, and the system normally acts on a simple TRUE/FALSE model. However uncertainty can be set by associating a probability to an item, as in TESTRESULT (0.95) = 1257 and there are demons to indicate how probability is to be calculated when, for example , the system is comparing two words, one of which might be mispelt.
Demons are also use to interact with the human user and the (QUERT) demon is used in the item QUANTITY (QUERY). When the CODIL decision making unit requests a value fo QUANTITY the (QUERY) demon is activated to ask the human user to provide a value. In an item such as UNITPRICE (QUERY) = 49 the human user is asked to confirm that the value 49 is correct.
The Lexicon
Logically the Lexicon is a CODIL set which contains the names of all the sets, but in the existing CODIL interpreters is held as a table to allow rapid access to the decision making units and to the input/output interfaces.
Each table entry includes the name of the set as text, and a number (hidden from the human user) used for internal data compression purposes. If the set is described as a file there is a link to the file, and the table may include all demons (which are inherited by all item members of the set. Obviously sets can be members of sets and may be linked as in FATHER (ISA) = PARENT and MOTHER (ISA) - PARENT.
[Over the next few weeks this post will be extended to include more example of the use of CODIL and hti spage will be updated to include links to relevant examples]
No comments:
Post a Comment