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:
endIf 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.
pr [You won't ever see this]
endWhen 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.
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.