Defining operations

Operations have outputs

An operation is distinguished from a command by having an output. In order to define an operation, then, we clearly need to know how to make a procedure output an object. As it turns out, nothing could be simpler though the idea is somewhat difficult to express in English. LOGO has a primitive command called op which takes one input. When op is invoked it causes the procedure it is found in to do two things,

Notice that it is a necessary consequence of this behaviour that no operation ever outputs more than one object.

A operation definition may in the extreme contain no more than an op command and a simple (direct) input. We can illustrate this with a procedure which on the surface seems to make LOGO behave abnormally.

You know that if you say print cat (without the double quotes in front of cat ) LOGO will say I DON'T KNOW HOW TO CAT (or THERE IS NO PROCEDURE CAT). This is because cat (not being a quoted word) looks like the name of a procedure and, in fact, no such procedure exists. But we can always define a procedure called cat and nothing stops us making this an operation which outputs the word "cat. All we need is one brief line for the body of the definition:

to cat
op "cat
end

If you try print cat once LOGO has accepted this definition, CAT will be displayed on the screen with no complaints at all, in exactly the same way that it would in response to print "cat. Since the procedure cat outputs "cat it is precisely equivalent in function to the quoted word "cat. Both evaluate to the same LOGO object.(fn1)
As it stands it is not obvious that it is op rather than end which brings cat to a halt. Adding an instruction after op makes it clear, however.

to cat
op "cat
pr [You won't ever see this]
end

When you now try print cat, you will see cat appear on the screen, but as op always brings about a shutdown, line 2 will never ever be processed.

Only use OP within a procedure

There is one rather special characteristic of op which puts it in a class of its own as a command although it follows naturally from the way we have described its effects. Op can only be used in a procedure definition. Since it needs to close down a parent procedure it can obviously only be used to proper effect when it is found within a procedure. Unless you enjoy error messages, do not therefore try to use this command at toplevel. To act as a reminder that op behaves more than anything else like an alarm signal we will enclose the procedure in the following type of box in instruction diagrams:

Simple procedures but powerful interactions

Although right now we are just taking first steps, we need not feel restricted to the development of toy procedures with little real purpose. The power of even the most sophisticated LOGO environments is achieved not through intricately structured procedure definitions but rather by carefully engineered conspiracies between a number of inherently simple procedures. A LOGO environment is typically a set of very basic tools so coordinated that they can be used to carry out complex tasks. Most constituent procedures will be defined in a half dozen or so lines. Many will be no more than skeletal one-liners.

One such tool which we will make frequent use of is a procedure - we will call it pickrandom -for selecting an element at random from a list or a character at random from a word. Dissecting the definition of pickrandom provides a nice illustration of the power available when even quite basic operaions are interlinked in a user defined procedure. As you will see, pickrandom itself takes a ride on a whole group of LOGO primitives, packing them altogether in one single instruction. Take a look now.



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

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