Reprint: CODIL 1970

Conference on Man-Computer Interaction,

Teddington, 2-4 September, 1970.

Published in proceedings, IEE Conference Publication No 68, pp 211-216, 1970

CODIL

by C. F. Reynolds

Introduction

In order to understand the problems of man-computer interaction it is necessary to understand something of the history of computing. The original computers were designed for numerical analysis and, for this purpose, the information about the application can easily be divided into an a priori list of operations (the program) and a separate list of numbers to be processed (the data). It was soon found that many highly repetitive data processing tasks could be handled using this approach, which has now been extended to cover an extremely wide range of applications. However, the more complex non-numerical applications often prove difficult. In particular large numbers of systems analysts and programmers are often needed because it is not possible for the users, (managers, clerks etc), to interact directly with the basic computer system. For many applications the provision of this human interface between the user and the computer represents over 50% of the cost of the application. This is a long way from the truly interactive system, where the user can approach an effectively empty computer and set up whatever application he requires.

It would seem that the way to progress might be to define the interactive requirements first, and then design a digital system to fit them, rather than by trying to define an interactive system to fit a stored program computer. The starting points of this approach are groups of people such as managers, clerks, scientists, housewives, etc, who have unspecified data processing problems to be processed by a 'black box'. They may be working individually or in co-operative groups, and the problems may be short and self-contained or long and interactive with other problems.

Only a very few things can be said about the 'black box'. It must be easy to understand and use, and both flexible and robust. It must be able to input, output and store strings of information of almost any length. A list of general purpose functions covering simple arithmetic, editing, file amendment, sorting, etc, is also essential. These features must be linked together by a control system which organises and executes the user's problems. It is quite clear that this control system cannot consist of a collection of application programs as, at this stage, no applications have been defined. The same difficulty applies to the definition of file structures and it is quite clear that the stored program approach is unlikely to be of much use outside the library of functions. This means that to construct the 'black box' one needs both a language to handle the information and an application independent control routine. A suitable information language, CODIL, has been defined and a control system has been based on a decision making model. This has been tested on a varied selection of applications.

CODIL. Context Dependent Information Language

If the control system could be constructed the ideal language might well prove to be the individual user's mother tongue. At a more immediately practical level CODIL has been designed to retain much of the flexibility of natural languages without involving their complex syntax structures. In many cases it is possible to translate English statements directly into CODIL. For instance the sentence "Macbeth murdered Duncan with a dagger" can be rewritten as "The murderer is Macbeth and the victim is Duncan and the weapon is a dagger." The equivalent CODIL statement is:

MURDERER = MACBETH,       VICTIM = DUNCAN,            WEAPON = DAGGER.

The basic items of CODIL are variable length data items such as "MURDERER = MACBETH", "CUSTOMER NUMBER = 12345", "YEAR > 1945" and "DISEASE NOT MEASLES". Each item. usually consists of a set name, a value defining a member of the set, and an operator that partitions the set. The set names form a vocabulary that defines the individual application and they have to be provided at the beginning of any new task. The usual operators are "=", ">", "> =", "<", "= <" and "NOT" and the values are simply those that occur naturally within the problem. Two additional operators, "ANY" and "NONE", are used to define the whole set and the empty set respectively. Under certain circumstances the set name may be used alone, as a label. The treatment of function calls such as "PRINT FILE = 145" or "MULTIPLY" is identical except that the names are provided by the system to ensure compatability with the function library.

A simple statement is a list of items separated by commas and terminated by a full stop. The order is unimportant except that the control routine may attach special significance to the terminal item. Compound statement are formed by eliminating common items from successive simple statements. This is represented by indenting successive items of the input/output format as can be seen by examining the following extract of a 'house for sale' index. For instance all the houses listed have one reception room, but this item is only stated once.

FILE = HOUSE INDEX,     RECEPTION ROOMS = 1,         BEDROOMS = 2,             TYPE  = FLAT,                 AREA = KEYNSHAM,                     PRICE = 2950,                         REFERENCE = 5.         BEDROOMS = 3,             TYPE = SEMI,                 AREA = HARTCLIFFE,                     PRICE = 3150,                         REFERENCE = 3.                 AREA = STAPLE HILL,                     GARAGE = DETACHED,                         BUILT = 1945.                              FEATURE = CENTRAL HEATING,                                 PRICE = 4250,                                    REFERENCE = 2.

Internally the indentation is reduced to an item counter, called the level, which acts as an implicit pointer that allows rapid reading, writing and processing of the compound statements with no look ahead and very little backtracking: For more complex structures, such as parts explosions, statements can be nested, as this example from the Forsyte family tree shows.

NAME = JOLYON FORSYTE,     BORN = 1806,         RELATION = FATHER.            !NAME = JOLYON 'SUPERIOR DOSSET' FORSYTE,            !    BORN = 1770,            !        RELATION = FATHER.            !           !NAME = JOLYON FORSYTE,            !           !    BORN = 1741,            !           !        MARRIED = 1768,            !           !            RELATION = WIFE.            !           !               !NAME = JULIA HAYTER.            !           !    OCCUPATION = FARMER,            !           !        PLACE = DORSET.            !           !    DIED = 1812.            !    OCCUPATION = BUILDER.            !    MARRIED = 1798,            !        RELATION = WIFE.            !           !NAME = ANN PIERCE.     DIED = 1850.         MARRIED = 1846,             RELATION = WIFE.                !NAME = EDITH MOORE.     DIED = 1892.

The Decision Making Unit

The system is controlled by a decision making unit. This works by comparing the facts of its immediate environment with criteria which may be relevant to those facts. At anyone instant the facts are represented by a simple CODIL statement and the criteria are held in a compound statement which is scanned for relevant data or function items. If a data item is deduced to be true it becomes a' new item in the fact statement; a true function item is obeyed.

This decision making unit can be readily simulated on a conventional computer and its simplicity can best be illustrated by describing the System 4 program, the Pilot Program, that is being used. This occupies 30K bytes of store and requires additional work space for holding the CODIL files being processed. 23K bytes of the program are used to handle disc transfers and the analysis and editing of the card input and printer output. The remainder of the program consists of the function library and a number of completely internal subroutines and tables. The whole decision making unit and its interface with the rest of the program consists of less than 200 Usercode instructions.

Applications

CODIL and its Pilot Program have only been used under test conditions. However a variety of non-numerical applications have been examined. The language is ideally suited for handling complex information and 'real life' files have been constructed covering the structure of I.C.L., biographies (1), organic chemistry (2), and biological fields records (3) A model invoicing system has been set up, based on the author's first hand experience, together with a number of associated commercial files. CODIL has also been used for problem solving (4) and the system fails to cross the seven bridges at Konigsberg (5), a problem that is topologically impossible. In the latter case it also prints out details of all unsuccessful attempts if required.

The pilot program has been designed to work independently of the input/ouput devices used but, at the time of writing, it had not been linked to an on-line device. However a 'Conversational CODIL' system has been set up using card input and printer output. All the sequencing routines, job libraries, indexes, etc, are described in CODIL, which is also the input/output language. All the above-mentioned applications can be run and new ones may be created and run 'on-line'. Such new tasks can even be entered into the job library if the user knows the appropriate non-print authority code.

The following examples are shortened extracts of a run of this system. Initially the system asks the user what job he wants to do. The reply is either a call to the job library, as in this case, or the description of a new job. For all searches the system requests the search parameters which here are quite simple, although complex nesting to terms is possible The answer printed out is the result of searching a 10K byte file of chemical data. The next example is the pricing of an order. Finally more information is added to an existing file of biological field reports and some errors in the input illustrate some of the systems 90 error reports. The run was on a 4/70 computer and the original, more detailed run took 7 seconds, including both the printing and disc access times.

This work was carried out in the Programming Research Department of International Computers Limited. The opinions expressed in this paper are those of the author and do not necessarily represent the views of I.C.L.

References

1. Who's Who 1965, Adam & Charles Black, London.
2. Albert, A. (1959), Heterocyclic Chemistry, The Athlone Press, London.
3. Hazelton, M. (1965), Fauna collected from Devonshire Caves, in British Hypogean Fauna, Cave Research Group of Great Britain. (and other later papers).
4. Hollis, M. (1968-70), Tantalizer series, New Scientist.
5. Ernst, G.W. & Newell, A. (1969), GPS - A Case Study in Generality and Problem Solving, Academic Press.