User defined procedures

The structure of a procedure definition

Using the editor

Knowing the form a procedure definition takes is, of course, only part of the story. You also need to know how to present such a definition to LOGO so that it may be learnt (and remembered).

In LOGO, defining procedures is normally carried out in a mode which we called earlier the editing mode.

Exactly how you enter the editing mode will depend on your particular system. Typically the editor is entered automatically as soon as you make any attempt to start the first line of a definition, but the editing mode can also be entered by issuing various commands which include, not surprisingly, the edit command.

The characteristics of editor interfaces are sadly system dependent. In some implementations, the screen display is dramatically different from that of conversational mode. In others, no more than a change in the appearance of the prompt provides the clue that different functions are being provided.

One of the useful functions you may discover, to handle the requirement that an instruction must not be split across two lines, is that your editor may allow you, for cosmetic reasons, to shift to a new screen line at some particular point in mid instruction. This is usually achieved using <tab> and normally (but not always) a continuation character, such as an arrow, will mark the point to distinguish these cases from real line breaks where a return has been used.

But perhaps the most important question you will need to resolve is how to get LOGO to take notice of whatever definition you have prepared in the editor. Oddly, it is usually the act of leaving (or escaping from) the editor - most likely by closing the editor window or by using some key combination such as the control key and the letter C - which is the vital trigger in the teaching process. Escaping back to conversational mode is how you will normally say: 'OK. These are the procedures I want you to learn. Now remember them!'.

Of course, you will need to establish all of the details as they affect your own situation by reference to your particular user manual or your local helpmate.

Look here for some help on the editor used with the Logo PLUS or Terrapin Logo for the Mac.

Fortunately, once you begin work inside the editor, consistency across implementations reappears. Procedure definitions themselves take a standard form.

Is the editor really necessary?

You may wonder at this point why you need two different modes of interaction. After all, if we can teach LOGO new names in conversational mode why not also new procedures? Well, in fact you can define procedures in conversational mode too. But there is a sharp difference between teaching names and teaching procedures which makes the tactic less appropriate under most circumstances.

Teaching names is essentially interactive. Even if it is premeditated, you can set up a variable using make in a single, short instruction. This is the normal way to deal with LOGO in conversational mode. A procedure, on the other hand, is a series of coordinated instructions designed to carry out some specific task. It may also be necessary to identify it as operating on one or more inputs. Defining a procedure is consequently a lengthier and more complex operation than assigning a name. Defining a procedure has more in common with writing a letter than with joining in a conversation. The editor - like a word processor - is simply there to provide you with a comfortable environment in which to compose your definition without LOGO looking over your shoulder as you go about the task. If you wish, you can even stay in the editor to define a number of different procedures at the same time. Only when you are quite happy with your specification do you escape back to conversational mode and, in so doing, hand your definition(s) over to LOGO.

Defining commands and operations

To flesh out first the simplest type of structure it will be easiest to begin by working through the definition of a new command. (This is the next page.) You should then move on to see how an operation might be defined.

Ron Brasington
Department of Linguistic Science
The University of Reading
Reading
UK

E-mail: ron.brasington@rdg.ac.uk