BFOIT Introduction to Programming     Defining Your Own Commands

Introduction

In this lesson you will learn how to add your own new commands to the TurtleTalk language.  You will teach the TurtleTalk interpreter how to do some new things.  This capability to name procedures that are made up of other already existing TurtleTalk stuff is called abstraction; and, as you are about to learn, is a big help in constructing good programs.

How To Write Large TurtleTalk Programs
That Do What You Want

Why?

As you are about to learn, an experienced programmer would think about how to solve the problem before she would start entering TurtleTalk commands.  An experienced programmer would break the problem into pieces that each are simple to do by themselves.  Then, put all the pieces together to solve the problem.

Let's play "experienced programmer" with the first exercise.

Understanding the Problem

You need to get the turtle to:

• draw 4 rectangles
  • one is tall and thin
  • three are short and form a stack of rectangles next to the first

- OR -

• draw 7 lines (4 horizontal and 3 vertical)
  • 4 lines form the perimeter of a big rectangle
  • 1 line splits this rectangle in half vertically
  • 2 lines split the right half of the rectangle into 3, equally sized rectangles

- OR -

• draw 13 line segments (6 horizontal and 7 vertical)

  This is hard to describe; so, I'm choosing not to go any further with it.  But, it is a way of looking at the problem.

This completes the "Understanding the Problem" phase. 

The next phase is "Devising a Plan" - how do you get the turtle to draw the things you've identified.

Devising a Plan

Let's follow our experienced programmer's thoughts through the rest of a solution.  She has chosen to draw a square (a special kind of rectangle) and subdivide it.  So, she needs to figure out how many turtle steps each side of the square needs to be.  Since it will be split in half and into thirds, she needs a length that is a multiple of 2 and 3.  She likes nice round numbers so she makes each side of the square 120 turtle steps (120/2=60; 120/3=40).  As you can see, it's nice to know a little bit of math when you're programming.

With this decided, she first writes her program down on a paper in pseudo-code.

   1. draw a square
   2. draw the vertical line that splits the square in half
   3. draw the top horizontal line spliting the right half
   4. draw the bottom horizontal line spliting the right half
   5. make the turtle invisible

Carrying Out the Plan

 

Pseudo-code (Written on Paper)	TurtleTalk Instructions (Typed on Computer)
draw a square	fd 120 rt 90 fd 120 rt 90 fd 120 rt 90 fd 120
draw the vertical line that splits the square in half	bk 60 rt 90 fd 120
draw the top horizontal line spliting the right half	bk 40 rt 90 fd 60 bk 60 lt 90
draw the bottom horizontal line spliting the right half	bk 40 rt 90 fd 60
make the turtle invisible	ht
Table 3.1

Our experienced programmer starts the TurtleTalk interpreter on her computer.  She reads her pseudo-code notes (converting them to TurtleTalk commands in her head) and types in the code.  As each line is [Enter]-ed she watches the turtle do exactly what's expected.

	Although it's not the most attractive house, it is easy to draw with the turtle. Make the front of the house a square with each side 100 turtle steps. Make the roof an equilateral triangle, with each side 100 turtle steps. Make the door 50 turtle steps high and 25 turtle steps wide. Make the window a square, 25 turtle steps on each side.
Figure 3.1

alt="Your browser understands the <APPLET> tag but isn't running the applet, for some reason." Your browser is completely ignoring the <APPLET> tag!

TurtleGraphics Applet

Defining Your Own Commands - Procedural Abstraction

But, my interaction with a computer consisted of getting a little bit of time on a computer I shared with hundreds of others.  So, use of paper and a pencil for the first steps was important.  But now everyone has their own computer...  Let's take advantage of this and eliminate the use of paper and pencil.

We're not going to change the steps in the programming process:

1. writing pseudo-code,
2. converting it to TurtleTalk instructions, and
3. typing your TurtleTalk program into the interpreter.

Instead, there's a way to replace the notes and pseudo-code on paper with stuff we type into the TurtleTalk interpreter.  We will use comments embedded in our TurtleTalk instructions and a technique called procedural abstraction.  For now, you can think of procedural abstraction as the ability for you to invent your own new TurtleTalk commands.  Each of your new commands will do something simple.  Your computer programs then become lists of your new commands. 

Procedural abstraction is the most important programming concept you will learn!

Let's work through an example.  It will give you a good feel for what I'm attempting to describe.

Pseudo-code	TurtleTalk Instructions
draw a box     with sides     = 100 steps	fd 100 rt 90 fd 100 rt 90 fd 100 rt 90 fd 100 rt 90
Table 3.2

By now you have to be good at drawing a square box.  Table 3.2 shows a pseudo-code description of what to do and its comparable list of TurtleTalk instructions. 

Here are a few problems I have with the list of instructions.

1. without the pseudo-code, it takes a non-trivial amount of thinking to figure out what the list of instructions does,
2. if it is in the middle of other instructions it is even harder to figure out what the combination of instructions does,
3. it takes a lot of time to type every time you want a square box that's 100 steps on a side, and
4. it consists of so many characters that it is easy to make a typing error.

What we need is the ability to give a name (also known as an identifier) to the list of instructions that draw this square box.  And, we need to make the TurtleTalk interpreter aware of this name and treat it just like the built-in commands it already has. 

We can do this.  The TurtleTalk interpreter allows you to create your own commands.  Here's how...

To define a new command that draws a box, 100 steps on a side, you type:

   to box100
     fd 100 rt 90
     fd 100 rt 90
     fd 100 rt 90
     fd 100 rt 90
     end

   to box100
     fd 100 rt 90 fd 100 rt 90 fd 100 rt 90 fd 100 rt 90
     end

So, what have we done here? 

We've used a very special command ("to") to teach the TurtleTalk interpreter a new command.  Just as it understands "forward" and "right" commands, it now understands what a "box100" command is and does.  We've defined a new command, also known as a new procedure.  Since a command is one kind of a procedure (there are others), from this point on I'm going to use the term procedure definition in place of command definition.

What does this special "to" command look like?

The general form, the syntax, of a "to" command, a procedure definition is:

to	<name>
	<TurtleTalk-Instructions>
	...
	end

Procedure definitions consist of:

1. a title line (the "to" line containing the procedure's name, its identifier),
2. a body consisting of one or more lines of instructions, and
3. an end line (the word "end")

Once you've defined box100 you can use it like any of the TurtleTalk commands you've been using.  You've just taught the TurtleTalk interpreter how to do something; you've added a command to TurtleTalk's vocabulary.

Either go back up to the TG applet or use a small popup TG applet to type in the definition of box100.  Try using it to draw a couple of boxes at different locations in TurtleSpace.

Then, try typing:

   box100 rt 45

Up till now, every time you typed TurtleTalk commands and pressed the "Enter" key, something happened to the turtle in the graphics area of the applet.  But, when you typed in "to box100" and then pushed the "Enter" key, nothing happened in TurtleSpace.  Instead, the CommandCenter name stripe changed:

"Defining Procedure: box100"

When you continued typing, adding TurtleTalk commands, e.g., "fd 100 rt 90" and hit the "Enter" key, again, nothing happened in the graphics area.  But, the "> " characters remained the prompt and the cursor was still indented a couple of spaces on each new line. 

Although it is not obvious, the TurtleTalk interpreter is doing something - it's checking to make sure that what you are typing is legal TurtleTalk.  If it is, what you are typing is just collected, stored away someplace, remembered for later use.  You are teaching the interpreter how to do something new and it is remembering what you are typing.

Finally, when you typed in "end" and the "Enter" key, (called the end line) the phrase "Defining&nbps;Procedure:&nbps;box100" disappeared in the stripe above the terminal area, the prompt characters went back to "? " and the cursor was no longer indented a couple of spaces.  You've completed the definition of the new command.  All of the stuff that changed - the stripe above the terminal, the prompt, the extra indentation - were feedback to you from the TurtleTalk interpreter, to make sure you knew that you were in the process of defining a command.

Once you have completed defining your new command, you can then use it.  When you type its name ("box100"), the TurtleTalk interpreter recognizes it and does what you told it to do when you defined it.  Typing its name to get the interpreter to perform it is technically called invoking it, a.k.a. calling it, doing it, performing it, ...

In summary, defining a procedure is teaching the interpreter how to do something, typing the procedure's name into the interpreter is invoking it - asking the interpreter to do what you taught it.

alt="Your browser understands the <APPLET> tag but isn't running the applet, for some reason." Your browser is completely ignoring the <APPLET> tag!

To make this process easier, I'm going to use the editor that's built into the TG applet/application.  To open the editor in the applet, click the right mouse button anywhere in the applet and choose the Window->Add Editor menu option.  In the application, choose the Add Editor option of the Windows menubar item (at the top).  Hold the left mouse button down with the mouse located on either the CommandCenter or Editor name stripes to grow/shrink the window sizes.

All right, so we want to write a procedure which draws a house.  Click the left mouse button in the editor window and type:

  to drawHouse

So what now?  Where do we go from here?  How can we break down drawing the house into multiple, simpler tasks?  What are the objects that make up our house?  That's it!  Let's break the procedure of drawing the house into subprocedures, one for each object.   Our drawHouse procedure will invoke four other new procedures:

1. drawFront - a procedure that draws the front of the house
2. drawRoof - a procedure that draws the roof on top of its front
3. drawDoor - a procedure that draws the front door, and
4. drawWindow - a procedure that draws the front window.

Add invocations to these procedures to your drawHouse procedure in the editor.  Make it look like this:

  to drawHouse
    drawFront
    drawRoof
    drawDoor
    drawWindow
    end

But, this is only legal TurtleTalk source code IF we followup and define all of the drawXxxx procedures we've invoked.  In fact, the moment you move the cursor out of the text that makes up the drawHouse procedure or take focus out of the editor (by clicking the mouse outside editor) error messages will pop up.  Checkout Figure 3.1.  Any time you write or modify a procedure, the editor makes sure the procedure is interpreted as soon as it thinks you are done with it.

Figure 3.1

You could just ignore the messages - click on their close boxes - but it is best not to do this.  Instead, what you should do is to turn the lines of source code that are not yet ready into comments.  When the interpreter sees a semicolon (";") it simply collects it and all the remaining characters on the line.  This text is assumed to be a note for the programmer and anyone else reading the source code.

So, change your procedure to:

  to drawHouse
    ;drawFront
    ;drawRoof
    ;drawDoor
    ;drawWindow
    end

  to drawFront

Repeat this process with the remaining procedures.  When you're done, you should be able to click in the CommandCenter, invoke your drawHouse procedure, and... get a house.

Did you get a house?  If not check your code and fix the mistakes.  If you did get a house, instruct the turtle to pick up the pen, move to another spot, put the pen down, and try invoking your DrawHouse procedure again.  Did you get a second house that looks like the first?  If not, why?

What your main procedure should do is to initialize TurtleSpace so that it is in a known, consistent state.  When you first start interacting with the TG applet/application, is in a state where

• TurtleSpace is empty/clean,
• the turtle is visible,
• the turtle is in the center of TurtleSpace, facing North,
• the turtle's has a black pen, two turtle steps wide, and
• the turtle's pen is down (ready to draw).

Working in TG is highly interactive.  As you write procedures and try them out, you modify state.  You move the turtle around; you change its heading; you change the color of its pen; etc...  Testing the parts of your program is great; this helps you write a correct program fast.  But, a well written program has a known starting point and state and this is main.  It should contain all of the commands needed to intialize TG's state properly. 

Here's an example main procedure for use with drawHouse.

  to main
    home clean setheading 0
    pendown setpencolor 0 setpensize 2
    drawHouse
    end

One BIG thing we learned in this lesson was how to write a program in phases:

    1. Understanding the Problem
    2. Devising a Plan
    3. Carrying out the Plan
  

    4. Looking Back
  

This has been your first exposure to the use of abstraction - the most powerful concept you will use as a programmer.

A Piece of History: In the mid seventies, I stopped in to see a new friend in his office.  He had stepped out for a bit, so I decided to wait.  I checked out his bookshelf and grabbed a small, plain-black book that had the title "Structured Programming" written by O.J. Dahl, E.W. Dijkstra, and C.A.R. Hoare.  A quick glance at its Table of Contents and the title of one chapter written by E.W. Dijkstra caught my eye - "On Our Inability To Do Much."  I scanned the chapter and knew this book was monumental; I had to buy a copy and read it.  This book is still in print, more than thirty years after it was published.  What this lesson has attempted to introduce to you was at the heart of the matter in Dijkstra's contributions to this wonderful book.