The basic components of instructions

Procedures and data

Most - though not all - programming languages aim, like Logo, to offer a way of communicating with a computer which is based on the notion of issuing instructions.

Looking at their form and function, a linguist would say, putting it crudely, that instructions are composed, like human language sentences, of verb like elements and noun like elements. To make the same point, the man in the street would perhaps want to talk instead of action (or relation) words and thing words, while the logician would no doubt identify predicates and arguments as the basic elements. To each his own terminology. Ask a programmer about the language he works with and the chances are that he will distinguish in the sentences of his program text, a set of words which represent procedures and another which represent objects (or data).

To get to grips with issuing instructions in a programming language, then, and to continue to talk like a programmer, it follows that we will need to become familiar with (a) the range of proceduresthe language provides access to (including the possibilities it offers for the user to extend this range) and (b) the kinds of object, i.e. the data typeswhich it is able to handle.

Of course, in a well designed language, the permitted data types and the built-in procedures are certain to be closely interconnected - for obvious reasons. You would not be pleased if you were asked to spell out the instructions for building a house and then found that, although you could talk about bricks and mortar, you could only refer to a set of procedures intended for making jam. But this interdependence of procedures and objects is not total. A language might indeed provide us with the right kind of procedures but not allow their application to the type of data we are interested in manipulating. And another might cope well with our data needs but not offer us the necessary procedures.

Since it is the purpose of this course to investigate the application of programming techniques to natural language processing, and since, to take an extreme case, it is clear that anyone primarily concerned with the computational handling of natural language is scarcely going to be impressed by the simple language embodied in a pocket calculator (designed to operate on numbers but not on alphabetic strings), we are going to begin by checking out the range of phenomena that Logo has been set up to deal with and the type of data structure which it provides for the purpose.

Once satisfied that the available data types will, in fact, suit our aims, we can then safely move on to consider how instructions in the language are built up using the data types and the procedures which Logo provides.

Ron Brasington
Department of Linguistic Science
The University of Reading