In the next few chapters we will cover a large chunk of material. Much of it may not make immediate sense to you. You will find that as you continue on in later chapters the material covered in these chapters will begin to make more sense. For this reason you should not skip over this chapter even if it doesn't all sink in all-at-once. Later, you can refer back to these chapters to help you fully grasp the concepts. This lesson covers the following topics:

• Program syntax
• Macro Header
• Comments and White Space
• Identifiers
• Keywords
• Program Statements
• Summary

Program syntax

In our first lesson we compiled a very simple macro. In fact, the macro we created is just about the smallest macro you could create. Here is that sample macro from the first lesson:

  PROGRAM test;
    BEGIN
      wrterr ('Hello World!');
      pause (5.0);
    END test.

This program contains all the requirements for a DCAL macro and not much more. Let's break this example down line by line.

Macro Header

The first line:

  PROGRAM test;

is the macro header. There are two types of headers in DCAL. The first is the PROGRAM header. The syntax is:

  PROGRAM program_name;

PROGRAM is a keyword that identifies this module as the main program file for this macro. More on keywords later.
You should recall from the introductory lesson that macros can be composed of one or more separately compiled code blocks. Each code block or module is a separate text file containing the code for the module. If a module is not the main PROGRAM file it is simply labeled as a MODULE such as:

  MODULE program_name;

The syntax is exactly the same whether your module is the main PROGRAM module or simply a standard MODULE. The other differences in these modules will be explained later.

Comments and White Space

You will notice that the second line in our listing contains no information at all. It is simply a blank line. These blank lines or other spaces in your source code are called White Space. The compiler will ignore White Space. While you could type all your code as one long run on sentence, it will not help either the compiler or your sanity. Be sure to develop a system for use of White Space. For example you may like to leave a blank line between different Procedures or Functions in your code. This will aid in readability. We will talk more about coding style as we progress with the tutorial.

Comments are simply notes put in the source code for the reader. They are ignored by the compiler. You should use comments liberally and sensibly. In our sample macro there was really no need for a comment since it is such a simple macro.

There are two types of comments that may be used in DCAL and they may each be used as desired. The first type of comment is the end of line comment. This type of comment is prefaced by the exclamation [ ! ]. The compiler will ignore all code that follows the exclamation (unless it is used in a string but we will cover that when we cover strings). Here is an example of our code with a comment:

  PROGRAM test;
  ! the following is the main portion of the code
    BEGIN
      wrterr ('Hello World!');
      pause (5.0);
    END test.

The third line in this listing is the comment. All the text following the exclamation is ignored by the compiler. Because of this you can even add comments to the end of lines that contain code. For example:

  wrterr ('Hello World!'); ! this will type out our message

Again all text following the exclamation is ignored.

The second type of comment is the multi-line comment. Often you will want to leave detailed notes in your code for later reference. Rather than prefacing each and every line with an exclamation you use the multi-line comment format. This type of comment begins with the left curly brace [ { ] and ends with a right curly brace [ } ] The compiler will ignore all text after the left brace and will only start reading your code after the right brace is encountered. Due to this syntax, comments of this type can span many lines. For example:

{ This macro will allow the user to determine the square root of a number. The user will be asked for a number and the square root will be displayed. This macro was written on 1/1/2001 }

Notice that we now are able to write long comments that span multiple lines. All the text within the braces is ignored by the compiler.

Two rules with comments are (1) you cannot nest comments and (2) you cannot place a comment within a text string. We will cover strings later. Nested comments would be a series of left braces before a right brace or an exclamation comment within a multi-line comment.

For example, the following would produce compiler errors:

{ comment line one ! this is a nested end of line comment

  comment line two }

Notice the end of line comment is contained within the braces. It may not be obvious when you nest comments accidentally. The compiler will catch these errors for you. If you use an editor that allows for keyword or syntax highlighting it will help to catch these sorts of coding errors before compilation.

As a further note on style, remember to add comments to your code. What makes perfect sense to you as you are writing the code may not make any sense later as you try to modify it. Also remember that others may read your code and comments make it much easier for them to follow. The other thing to try to do is only use helpful comments. While you could comment every line of code you should resist this temptation. Try to place comments only where your intent may not be clear or where you think an explanation of what the code is doing is required.

< Previous   |   Continue >

Table of Contents