Variable types

Two ways to create variables

In defining a command such as - or for that matter any other procedure which requires an input - we come across a way in which a name can be assigned to an object without the use of make. There are, then, at least two different ways in which variables may be created in LOGO.

  1. The command make can be used to associate a name with a thing.

  2. When a procedure accepts an object as an input, that object is automatically associated with a name.

But this difference in the setting up of variables is not merely a matter of technique. Along with it goes a considerable difference in the status of the two different types of variable created.

When an input to a procedure is assigned a name, this is a temporary expedient adopted only to guarantee that the input is processed correctly according to the instructions. For this reason, as soon as the procedure has carried out all of its instructions, the name is immediately discarded.

It is easy enough to check that this is indeed the case. First define, as before, using :times to identify the input variable name. i.e:

to :times
repeat :times [print [ ] ]

and then call the procedure with whatever input you like - e.g. type 5.

As soon as has displayed on screen the appropriate number of blank lines to match your input, straightway type print :times (or equivalently print thing "times) to see whether you can access the input variable and discover its value. You cannot. You will be told THERE IS NO NAME TIMES (or TIMES HAS NO VALUE). In other words, the variable no longer exists.

Global versus local variables

An input name used by a procedure is rather like a cloakroom tag. You might, of course, have your own label on your coat which helps you to recognize it. As far as the cloakroom attendant is concerned, however, your coat is the thing that hangs on the peg that corresponds to tag J23. When later on there is an umbrella on the peg, that becomes J23. When there is nothing on the peg, the tag J23 is out of business. A name set up in a procedure definition and a cloakroom tag are only of real interest to those directly involved. No-one else needs to know about them. The usual way for programmers to talk about such a state of affairs is to say that the names assigned to procedure inputs in LOGO are names for local variables. A local variable is accessible only by the procedure which creates it or by sub-procedures which that procedure may call. In other words, it is only available when its parent procedure is running.

Variables created using the command make are, by contrast, always available - both to the user at toplevel and to any procedure. They form part of the general LOGO environment. Variables created with make behave as global variables. This is true whether make is itself invoked at toplevel - by the user typing an instruction at the keyboard - or invoked in an instruction within a procedure.

Another way to create local variables

Setting up variable names to identify the inputs to procedures is, as it happens, not the only in which local variables can be created. The command local may be used inside a procedure with a variable name as its input, e.g:

local "junk

In using this command, you declare that the "junk will be known as a variable name only within the current procedure (or procedures called by it). "junk is, in this respect, just like an input variable name.

The existence of local variables has implications for the behaviour of make. We noted above that variables created by make are global variables. This remains true. But when make is used within a procedure and takes as its first input the name of a pre-existing local variable - i.e. either an input variable or a variable which has been introduced with the command local - this variable remains local. In other words, make may change the value of an existing variable but it cannot change its status.

It is not difficult to subvert the new flexibility of, for example, by changing the definition to:

to :times
 make "times 2
 repeat :times [print [ ] ]

Although the consequences of the change seriously affect the workings of, this particular use of make does not set up a new global variable "times. It sabotages merely by altering the value of the local variable which is initially set up when the procedure begins to run.

Keeping local and global variable names distinct

The distinction between local and global variables is not difficult to grasp, but the side effects which follow from the distinction can sometimes cause confusion. Because local and global variables are of different status, LOGO is quite happy for the same word to be used at the same time for both a global name and a local name. There is nothing stopping you defining as we did above and at the same time setting up a global variable "times using the command make at toplevel (or even in another procedure). Try it, and see what happens when you change the value of the global variable "times and the value of the input to

While LOGO has no problem keeping the two variable names "times (and the two associated values) quite separate in its own mind, you might not be so successful in your own, especially in more convoluted situations. The best advice, therefore, is not to take advantage of LOGO's permissiveness but try to keep your global variable names distinct from the local variable names which you set up in defining procedures.

Ron Brasington
Department of Linguistic Science
The University of Reading