Variables

Names of things

You have seen that words in LOGO may be used as the names of procedures. Primitive commands and operations, for example, have names - like print and butfirst. But words can also be used as the names of objects (or things). The main difference is that, on startup, LOGO knows almost no names of objects. Or, to put it differently, in most implementations there are very few primitive names. It follows that names for things in LOGO must for the most part be taught.

Why do you need names?

As you experimented with first, butfirst and other primitives in Things to do 1 you may well have found it tedious to type and retype long lists which you started to construct as interesting examples of content and structure. You might indeed have resorted after a while to the sensible tactic of reducing your lists and even words to skeletal structures capable of testing the behaviour of the procedures with minimum fuss and maximum efficiency. In this situation you can see at a practical level that a name would provide a very convenient way for the LOGO user at toplevel to cope with complex objects which need to be dealt with repeatedly. It is clearly infinitely preferable to type something like ark in a series of instructions print last ark, print butlast ark rather than having to type:

[[a.deck[lions[henry elsa]][tigers[raj sheba]]] [b.deck[goats[billy nanny]] [rabbits[thumper brighteyes]]]]

Names offer, then, a kind of shorthand. But there is another more important advantage to names which becomes clear if we follow up Noah's problem.

In loading his animals onto the ark, Noah no doubt had to drive them two by two into a crate on the quayside so that they could easily be hoisted on board by crane. Possibly he used a signal Animals OK when they were ready for lifting. Now animals in this context, is a name which refers to the next pair of animals to be loaded. But notice that at different times of day animals refers to a different pair of animals. Names are, thus, convenient for referring to types of objects whose particular instances or characteristics may change from time to time. When my wife says: Have you got the shopping list? she does not mean today what she meant last week, at least as far as the contents of the list are concerned.

As soon as we have made this distinction between an object and the name it is known by, we allow of course, not only the possibility that the same name may be used on different occasions for different objects but also that the same object may on different occasions be known by different names. The elephants Babar and Wilhelmina may at one point be known to Noah as the animals but after sailing they may be referred to as the cabin A3 passengers.

Variables, names and values

In technical accounts of most programming languages, the notions of name and object would normally be introduced in the context of a discussion of variables. In a sense, a name and the object to which it refers to are like the head and tail of a coin: they are two different aspects of the same thing. And very often it is useful to refer to this conjunction, this thing as a whole. It is in such a case that the term variable is convenient. In the presence of this new term, however, the word object becomes somewhat less appropriate and is in fact not commonly used. We will usually say instead that a variable has a name and has a value (though, of course, that value will necessarily be a LOGO object). We will also say, for brevity, the variable "animals rather than the variable which has the name "animals. These ideas are probably already familiar to you under the same names from elementary algebra or perhaps from using spreadsheet applications. If they are not, and if they are perhaps initially difficult, then one way to get a concrete grip on the idea is to think of a variable as a box which has a name on it (like Noah's crate labelled Animals or the cabin with a door marked 'A3') and to think of its value (the object) as the contents of the box (or crate or cabin).

Naming in conversational mode

LOGO provides for names and naming (i.e. for variables) in more than one way. It is easiest to start by looking at the most direct technique - the one you would use in conversational or direct mode. To give a Logo object a name - to create a variable> - you use the command make. The syntax is:
make "name object or if you prefer make "variable.name value

e.g. make "shopping.list [bread butter cheese]

Take careful note of the double quote in front of the name. If the first input to make is not a directly provided word as it is here, then it must be an expression which evaluates to a word. This is because what you are saying to LOGO is: Remember this specific string of characters as the name of the following object. The second input to make, on the other hand, can be any expression you like and it can be as complex as you like.

The association, between name and object once set up, is only as permanent as you decide. Further appeals to make using the same name will change the assignment. If you have already issued the instruction make "shopping.list [bread butter cheese], a second instruction make "shopping.list [tea milk] will completely replace the original value of the variable known as "shopping.list .

What's in a name?

As well as giving names to objects you will also frequently want to find out what particular object is referred to by some name, just as you might ask: What's in the shopping list today? To discover or retrieve the object with a given name you use the LOGO primitive operation thing. Thing takes one input and returns a value. thing "shopping.list (again be careful to use the double quote) outputs the object currently known by the name "shopping.list.

Since retrieving an object via its name turns out to be so often necessary, LOGO has fortunately a shorthand version of thing. Instead of thing "shopping.list you can say :shopping.list. The instruction print :shopping.list is thus exactly equivalent to print thing "shopping.list, and much quicker to type!

New objects from old

Putting the ideas of naming and object retrieval together, you can, of course, use complex expressions as the second input to make which themselves involve the retrieval of objects through their names. Make "weekend.list se :saturdays.list :sundays.list combines two existing named lists into a a new object known as "weekend.list.

That is not too difficult to understand. But what is important to realise in this case is that the variables called "saturdays.list and "sundays.list still exist in their own right after the creation of the new variable "weekend.list. When the primitive thing (or its shorthand equivalent) outputs an object associated with a name, it really outputs only a copy. It is rather as if the thing robot says: O.K. Here you are. This is what the object looks like, instead of saying O.K. Here's the thing of that name.

In this respect, thing is like LOGO procedures more generally. They are non-destructive. First "cat outputs "c not because it strips "c from "cat - leaving behind "at - but rather because "c is what you would get if you did strip the first letter from "cat.

It follows from this that if you want to modify the value associated with a variable name like "shopping.list on the basis of its current value, for example by adding something to the top of the existing list, you must say make "shopping.list fput "jam :shopping.list. If you just say simply fput "jam :shopping.list, you will get you an error message along the lines of YOU DON'T SAY WHAT TO DO WITH [JAM BREAD BUTTER CHEESE] or RESULT: [JAM BREAD BUTTER CHEESE]. Fput merely outputs what you would get if you did stick the first input at the front of the list which forms the second input. Despite appearances, it does not alter either of its original inputs. One of the most common mistakes of LOGO beginners - and not such beginners - is to interpret procedures with names like fput or reverse as if they actually did the job their names suggest. Remember, LOGO procedures are much too cautious for that.

Names are just words

A word used as the name of a variable is clearly special and for this very reason LOGO keeps a record of words which we have decided to use in this way. But a word which happens to be used as a variable name is none the less from any other point of view just a word like another. This means, then, that it may itself be given a name. Or, if you prefer, a string of characters acting as a the name of a variable may at the same time be itself the value of some other variable.

Suppose we use make to associate the name "animal with the object "cow by saying: make "animal "cow. Nothing prevents us saying at once: make "cow "daisy, in order to set up a variable with the name "cow and with the value "daisy. And nothing in this would prevent us from going on further to use "daisy as a name of something else if we wished.

If you like to think again of variables as boxes and their values as the objects inside the boxe, then what we are seeing here is something like nested Chinese boxes or Russian wooden dolls. A labelled box has inside it a labelled box which has inside it a labelled box which . . . This lack of distinction in their form between names and object words has a serious purpose in LOGO as you will see. But for now, you just need to know that saying to LOGO print thing "animal will result in it displaying the word COW - assuming the two make commands above - while print thing thing "animal will get DAISY to appear on the screen:

As far as shorthand techniques are concerned, thing :x is a legal variant on thing thing "x, but LOGO does not allow you to stack up colons. So ::x is not allowed, however desirable you might feel it is.

Recap on LOGO 'punctuation'

Words with no special marks - e.g. list - are taken by LOGO to be names of procedures. Quoted words - i.e. those directly preceded by ", like "list - are objects to be taken literally. Words preceded by : - e.g. :list - are names of things and the expression :list outputs (is equivalent to) the object associated with the name "list.

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

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