Lesson 3 -- Variables

Variables are placeholders for data that will be manipulated in the code. In order to work with data we need two things, a name for the data that we will work with and a place to put it. We get both of these things when we declare our variables. Here is the variable declaration section of the ARROW.DCS sample macro.

  VAR arrwidth : real; { the width of the arrow }
  init : boolean; { false (by default) until the macro is first run }

First we see the VAR keyword which tells the compiler we are going to declare some variables. Next we see the name of the first variable. If you remember our discussion on identifiers in Chapter 2 you will notice that the variable names meet all the criteria for valid identifiers. The variable name is followed by a colon and then the variable type. We discussed some of the different types in the previous section. You can use any valid type of variable whether it is a standard DCAL type or one you have created and declared yourself. Notice the use of the comments to explain what each variable is used for.

If you need to list more than one variable on a line you may separate them by commas. You can only group variables in this manner if they are all of the same type. This would look like:

  var1, var2, var3 : integer;

this declares three integer variables. You can do whichever looks best to you.

When the compiler comes across the VAR section in your code it allocates memory space for the data that will be held by these variables. You don't have to worry about how much space is allocated or how it is done. Simply remember to name your variables. If you fail to declare a variable and try to use it you will see an error 'UNDEFINED SYMBOL'

Variables can have what is called scope. The scope of a variable determines where you can use it. If a variable is declared within a procedure or a function it is said to have local scope and can only be used within that procedure. If you declare a variable at the top of your code listing, outside all of the different procedures and functions that make up your code, the variable is said to be global. A global variable can be called from anywhere in your code. Another way of looking at this is to say that all procedures will 'see' a global variable but that a variable declared within procedure 'a' is 'hidden' from procedure 'b'. It may be tempting to declare all your variables as global but it is not the most efficient way. As you work with DCAL more you will learn where to declare variables to achieve the desired results.

Now that we have declared a variable how do we put data into it? To place data into a variable we use the assignment operator. The assignment operator is a colon followed by an equal sign (:=). Do not confuse this with the plain equal sign. The plain equal sign is an operator used to test whether one item equals another.

Lets look at the ARROW.DCS macro again for some examples of what we have covered thus far:

  VAR
    ent : entity;
    pnt : ARRAY [1..7] OF point;
    tmppnt : point;
    i : integer;
    j : integer;
    ang : real;
    len : real;
    cose : real;
    sine : real;

  BEGIN
    {
This section of code calculates the x and y values for the 7 points of the arrow. All of these calculations assume a local origin which is coincident with the center of the tail of the arrow. The 7 points are translated and rotated to reflect the position of the two input points pnt1 and pnt2.
    }

    len := distance (pnt1, pnt2); { arrow length from end to tip }
    ang := angle (pnt1, pnt2); { angle arrow makes with the +x-axis }

    pnt [1].x := 0.0;
    pnt [1].y := -width / 4.0;

    pnt [2].x := len - width / 2.0;
    pnt [2].y := -width / 4.0;

    pnt [3].x := len - width / 2.0;
    pnt [3].y := -width / 2.0;

Hopefully by now much of this is starting to make sense. At the top of this piece of code we see the variable declarations local to this procedure. Notice the different types used. Next we see the keyword BEGIN. This keyword tells the compiler that we are done with the variables and what follows will be the statements of this procedure. Whether you have variables or not you must always preface your statements with the keyword BEGIN. This keyword tells the compiler that this is where the real work starts. Of interest to us is also the comment. This is a good use of a comment to explain what this procedure will do. Notice that the comment is of the multi-line type and is started and ended with the correct braces.

After the comment we come to some statements. Let look at the first one. On the left it starts with 'len.' Refer back up to the variable section and notice that 'len' is declared as a real type variable. 'Len' is followed by the assignment operator which tells the compiler to evaluate what follows and store it in 'len' In this case what follows is the DISTANCE function which is used to calculate the distance from 'pnt1' to 'pnt2.' In typical DCAL practice the working portion of the code is ended with a semi-colon.

The DISTANCE function is a built in function of DCAL. So what is the story with pnt1 and pnt2? They appear to be variables but aren't .html in the VAR section. They are variables of a sort. They are what is known as parameters. Parameters are variables that are given to a procedure or function to use. We will explain this more later. For now focus on the fact that they are another kind of variable. Variables can come from different locations. They may be local or global variables or they may be parameters of the procedure.

The next line follows the same pattern. variable 'ang is assigned the results of the calculation performed by the ANGLE function. Again pnt1 and pnt2 are used.

Pay close attention to the lines that follow. These lines show how to fill an array with data. If you remember the discussion on arrays then you will recall that you need to access the individual elements of the array by using its 'index'. The index is simply the number of the data item in the array. So looking up again to our VAR section we see that the pnt variable is declared as an array of points of which there are 7. The last few lines in this sample of code fill the individual variables of the array with data. To put some data in the first array element the format

  pnt [1].x := 0.0;
  pnt [1].y := -width / 4.0;

is used. This assigns x and y values to the first point in the array of 7 points. Since the sample macro is only drawing a 2d arrow a z value is not needed. The 'width' variable is again a parameter of the procedure.

For the complete listing of this sample macro, ARROW.DCS, refer to the SAMPLE subdirectory where you installed DCAL.

Hopefully you are getting comfortable with what we have discussed in these last few sections. As always if it doesn't make perfect sense, just hang in there. In time it will become more and more clear until it becomes second nature. You can always refer back to this section later to brush up.

We have covered a great deal in a few topics in this lesson. We have even touched on things that won't be fully explained until future lessons. Since we are working with the ARROW.DCS sample macro, it would probably be helpful to review it and work with it. Try changing the names of some variables and compiling the macro. See if you can determine the impact this has. The macro also relies on the constant tofeet. We discussed the use of this constant. Experiment with what happens if you double this value. What if it is set to 1.0? Try to read through the sample macro and see if the comments help you understand what is happening. This macro relies on arrays a bit so study the use of arrays. If you come across something in the code that doesn't make sense try to determine if it is a DCAL procedure or function and try to locate it in the manual to determine what it is doing. For example at about line 215 there is a command lblset ( 1, 'Width'); What is LBLSET? Why is it followed by the values shown? What happens when you change that string? What happens when you change the number 1 to another value?

Try the exercises outlined above. The purpose is to learn the material we covered in this and previous lessons. It is also important to get comfortable with the DCAL manual and working with the compiler. In addition, if you modify the code you are almost certain to have problems compiling the code. This is good practice and will help you later when you are not certain where the error lies. At this point these controlled experiments will help you learn to spot the errors since you will be introducing the errors yourself through experimentation. Most importantly read the sample macros and see how much you understand. As we progress you should understand more and more. You should also begin to see patterns and the way DCAL works in general.

Experiment and have fun.

End of Lesson 3

< Previous   |   Continue >

Table of Contents