Make your own free website on

Discussion #3 - Defined Procedures and Local Variables

One of the important features of Logo is the ability the language gives you to expand the original list of procedures that the Interpreter is able to translate. You may teach the Interpreter how to translate new procedures whenever you wish, thus increasing its power and usefulness tremendously. Procedures that the Logo designers created and that the Interpreter knows how to translate into machine language when you start the Logo program are called primitive procedures. New procedures that you create on the flip side of a page and that the Interpreter translates into machine language when you flip back to the front side of the page are called defined procedures.

The "flip side" of a scrapbook page is used to define new procedures. To flip a page you either press  <COMMAND> F or click on the F box in the upper right corner of the screen. Repeating either of these techniques will return you to the front side of the page when you have completed writing the definition of your new procedure. Sometimes the instructions for a defined procedure are written first in the command center and then copied to the flip side of the page, using the Copy and Paste features from the Edit menu on the Menu Bar at the top of the screen. At other times the instructions are typed directly onto the flip side of the page.

To alert the Interpreter that it is about to learn a new procedure, you type the de-limiter TO, followed by the name you have chosen for your defined procedure. To identify the end of a new procedure you type the delimiter END on a line by itself following the last instruction. TO and END are neither procedures nor expressions; they are the program elements, called delimiters, used to alert the Interpreter that you wish to define a new procedure and that you have completed the definition.

There are three parts to a defined procedure. For example: the Title line: TO SQUARE an instruction line: repeat 4 [fd 100 rt 90] the End line: END As you see, I used bold face type for the name of my defined procedure just as I have for primitive procedures. I used capital letters for the delimiters TO and END and for the procedure name to emphasize the special nature of the Title line and the End line. These conventions (using capital letters and boldface) that I find useful as a programmer and teacher, are not required by the Interpreter.

New procedures are defined on the flip side of a scrapbook page. The delimiters TO and END cannot be used in the command center. When you return to the front side of the page after defining a procedure on the flip side, the Interpreter translates what you have written into machine language and - if everything checks out OK - adds your new procedure to its vocabulary. If the Interpreter runs into difficulty while translating the procedure, it sends you an error message explaining what is wrong. You can then remove the bug by returning to the flip side of the page and correcting the faulty instruction. When you flip back to the front side, the Interpreter tries again to translate your new procedure. Once the procedure has been successfully translated by the Interpreter, you can execute your procedure by typing its name in the command center, just as you would for a primitive procedure.

There may be several instruction lines in a defined procedure. Although the Interpreter does not care how long your defined procedures are, I suggest that you try to keep them as short as possible in order to make your programs easier to read and debug. A good rule of thumb is that defined procedures should be no longer than the number of lines that can be displayed at one time on the flip side of a page.

Defined procedures may require one or more inputs, just as primitive procedures do. The expressions that provide inputs to defined procedures are always in the form of dotted words, which are the names of variables. A variable is an input that has previously been stored in the computer's workspace. It has both a name (that identifies which stored value to use) and a value (that is the number, word, or list to be passed back to the procedure.) A variable may be defined as "a named value" or "a name-value association." Here is the square procedure defined above, this time with an input: the Title line: TO SQUARE :LENGTH an instruction line: repeat 4 [fd :length rt 90] the End line: END An expression that names the input variable is written on the Title line following the name of the procedure.

I find it helpful to write this variable name in capital letters on the Title line, just as I wrote the procedure name in capital letters there, but this is just my convention; it is not required by the Interpreter. While I am on the subject of my own preferences in programming and writing style, let me add that I do not use capital letters for defined procedures or for variables when they are used in the instruction lines of defined procedures. I only use them for emphasis on the Title lines. I shall, however, use capital letters to identify variable names in the text of this book as a visual device for identifying them, just as I use boldface type as a visual device for identifying procedure names.

Including a variable name after the procedure name on a Title line alerts the Interpreter that it will need to evaluate an expression before the procedure can be executed, and tells the Interpreter the name to be associated with the input value. The variable is not actually created until you call the procedure by typing its name in the command center. After typing the procedure name, you type the value you wish the Interpreter to associate with the variable named in the title line. The Interpreter then assigns this value to the variable by associating it with the variable name and storing it in the workspace. Later on, when this input is requested by one of the commands in the procedure, the Interpreter retrieves the value and passes it to the command.

If you were to read the title line of this procedure aloud, you would say "To square dots length," which is a short-cut way of saying "To square, using the value of the variable named LENGTH as an input." If you were to read the instruction line of this procedure aloud, you would say "Repeat four forward dots length right turn ninety," which is a short-cut way of saying "Repeat four times the steps in the instruction list whose value is 'forward the value associated with the variable named LENGTH, right 90 degrees'." When you call the procedure, you type its name and the value of its input variable in the command center, for example: square 50 The Interpreter locates the procedure square in the workspace and notes that it requires an input variable :LENGTH. It checks your procedure call, and finds that you typed the numeral 50 after the procedure name. The Interpreter then creates a variable by evaluating the numeral and assigning the number 50 to the variable :LENGTH. The Interpreter can then proceed to execute the instruction line in the square procedure. Each time the Interpreter executes the quoted instruction list, it sees that fd requires the value of the variable :LENGTH as its input. The Interpreter evaluates this dotted-word expression by checking the workspace location named LENGTH, retrieving the number 50 that it had previously stored there, and passing this value to fd.

Variables whose names are written in the title line of a defined procedure are called local variables because they may be used only by commands in that procedure. This limitation is described by saying that the scope of the variable is the procedure whose title line includes it. Local variables are created in the workspace when the procedure is called and they are erased from the work-space when the Interpreter reaches the END line of the procedure. After drawing square 50, suppose you wanted to draw a smaller square and typed: square 25 The Interpreter creates a new variable by assigning the number 25 to the variable :LENGTH. The original variable named LENGTH - the one that was created for square 50 - was erased from the workspace when square 50 ended, so there is no confusion when the Interpreter creates a new variable with the same name.

I find it helpful to visualize a variable as a window-envelope (like the envelopes used to mail business statements) containing a bill. The return address on the envelope is like the name of the variable. The bill inside the envelope is like the value of the variable. Placing the bill in the envelope so that it can be seen through the window is like assigning the value to the variable. When the Interpreter is told to evaluate a dotted-word expression ("retrieve the contents of a particular envelope") it locates the envelope ("go to the return address printed on an envelope in the workspace"), checks the contents ("peek through the window on the envelope"), and delivers a copy of what it finds there to the procedure that requested the input. When fd tells the Interpreter to evaluate :LENGTH in the square procedure, the Interpreter searches the workspace for an envelope whose return address is LENGTH, peeks through the window and finds the number 25 that it had stored there when the procedure was called, and delivers this value as an input to fd. The defined procedure square is a command, because it produces an effect - drawing a square on the scrapbook page. It is also possible for you to define procedures that are reporters.

Reporters, you recall, do not produce effects. Their purpose is to output a value for a command to use as an input. Here is an example of a defined reporter:

  op 5
The command op (output) provides an output value for the procedure red, and thus makes red a reporter instead of a command. op requires one input, which it uses as the output value for the procedure. The Interpreter evaluates the defined reporter red by calculating its output value (the input to op).

Defined reporters such as red provide useful additions to LogoWriter's primitive procedures. This procedure, for instance, permits you to write the instruction setc red instead of having to look up  the color number on the Colors page every time you want to use it. If you had a whole set of these defined reporters (blue, green, yellow, etc.) and if they were available for you to use on any page that you were working on, it could be very useful indeed.

Defined procedures that are useful in other programs are called tool procedures. They may be stored on a page of the LogoWriter scrapbook named Tools. This page may be automatically loaded into the workspace every time you start LogoWriter by adding a page to your scrapbook named Startup, with one procedure on it also named startup, defined as follows:

  gettools "Tools
When LogoWriter is started, the Interpreter automatically looks to see if there a page named Startup with a procedure named startup on it. If it finds such a combination, it automatically executes that procedure. The instruction gettools "tools loads all the procedures on the Tools page into the workspace, where they are available for use on any other page. These tool procedures do not appear on the flip side of the page on which you are working; they are available - just as primitive procedures are available - for you to use whenever you want them.  After loading the Tools page procedures into the workspace, the commands cc and contents clear the command center and then display the Contents page so you can start using LogoWriter as usual.

Exploration #3 New Delimiters

TO Typed at the beginning of the title line of a defined procedure. Signals the start of the defined procedure.

END Typed on a line by itself following the last instruction line of a defined procedure. Signals the end of the defined procedure.

New Commands

output (op) number, word, or list Provides a defined reporter with its output value, which is the same as the input that is passed to op.

gettools tools Loads the tool procedures stored on the page named Tools into the workspace, where they are available for use on any scrapbook page just as if they were primitive procedures. startup The procedure named startup is executed automatically when Logo-Writer is loaded into a computer, if it is stored on the flip side of a scrapbook page that is also named Startup.

1. Experiment with the two examples of defined commands, changing them to draw polygons other than squares and using the Total Turtle Trip Theorem to calculate the proper angles. Define appropriate procedures named square, hexagon, octagon, triangle, and circle.

2. Defined procedures, like primitive procedures, may require more than one input. Revise the sample procedure by adding a second input for the number of angles in the polygon. TO POLY :LENGTH :ANGLES When you call the procedure by typing its name in the command center, you must include two numerals, which the Interpreter will assign to two variables in the order in which the variables were named on the Title line. Since this two-input procedure may be used to draw any type of regular polygon, I named it poly.

3. Add a third input to poly, such as a color number, and an additional instruction line setting the turtle's pen to this color.

4. Write defined reporters that output the color numbers of colors you are likely to use in the future. Save them on a page named Tools. Write a startup procedure that stores these tool procedures on a page named Startup, so that the Interpreter will store your tools in the workspace every time you start LogoWriter. You may be adding more procedures to your Tools page as you progress through this book.

5. Add instructions to the procedures you wrote in problems 1 and 2 which will fill the polygons with a selected color.

6. Do you suppose you could define procedures to draw different kinds of stars? What inputs would you want to use?