[[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.
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 .
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!
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.
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:
far as shorthand techniques are concerned, thing :x
is a legal variant on thing thing
but LOGO does not allow you to stack up colons. So ::x
is not allowed, however desirable you might feel it is.
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 ",
- 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.