HOME - - - - - - - - - Other material for programmers - - - - - - - - - Pascalite Tutorial Table of Contents

Pascalite Programming: Generalised Program Structure: Basics

This tutorial has less hands on material than usual; it is more theoretical. If you work through it, though, you will be able to write working programs with less trial and error along the road to finding out what is allowed.

     1) Every Pascal program begins with the word "program".

     2) Every Pascal program ends with a period (full stop).

Boy! If only the rest of this was going to be so simple! Unfortunately, I must now devote a few paragraphs to explaining some basic terms, and to explaining how I'm going to write things. Happily, much of the material in this tutorial is implicit in things you already know. The time to get a rigorous grasp of those ideas will be well spent.

Just before we delve into the rigorous stuff, here's the world's smallest (and most useless... well... it's harder to be more useless than completely useless, isn't it!) Pascalite program:

program a; begin end.

The WORLD's smallest Pascal program would be...

program a .

Those two gems are here for a reason. They are a starting point for the rules I will develop, rules which define what is allowed in a Pascal program.

I am writing this paragraph after "finishing" the rest of this. Whew. There is a lot of material here, and it isn't presented perfectly. Even so, I'd commend it to you. Read through it without worrying too much about things that are not clear. Then re-read it in a week or so. And again in a month or so. As your grasp of Pascal increases, so will your ability to see what I'm trying to convey. The good news: You don't have to know everything that is here to program in Pascal. But if you know what's here, you'll spend less time on mysterious syntax errors which stop your program from running.

In what follows, anything presented...

in this font

.... which isn't merely a program, or fragment of a program, will be a mixture of things in upper case (capital letters) and lower case ("small" letters). Anything in lower case (and punctuation marks) should appear in your work exactly as you see it in the tutorial, although you can introduce upper case letters if it helps make the program readable. Anything in UPPER CASE will need to be replaced by something defined by the word in upper case. So, for example, the following.....

program NAME;
begin
end.

... would say that Pascal would allow the following "program":
program verysimple;
end.

... but you can't use just anything for the name.

Typically, I will explain what is allowed for something like NAME before I give you the rule using it. The following rule for NAME will not get you into any trouble, although it won't cover every obscure legal name....

A NAME should start with a letter. After the letter, you can place letters or digits.... only.

A NAME may not consist solely of one of the words built into Pascal, the "Reserved Words" (There's a list in the help file). "program", "begin" and "end" are reserved words we've already mentioned in this tutorial. You are, however, allowed to make up NAMEs which incorporate reserved words, so "myprogram" would be okay. Such things would usually be written MyProgram to make them more readable. Because of the special use for upper case letters in this tutorial, I won't always do that here, but when you see just a few upper case letters in something, don't imaging I mean those letters have to appear as you see them.

So: Some allowed NAMES:
MyProgram, Program5.

Some NOT allowed names: A Cool Name (uses spaces), 99BottlesOfBeer (Doesn't begin with a letter), Program (One of the reserved words), Black+White (uses a punctuation mark. You may, and some people do, use some punctuation marks. The underscore character (_) is popular. I would advise against using any.)

Okay so far? Moving on....

Next we need to define legal VARIABLE-NAMEs. Again, this definition leaves out some legal names, but keeps you safe.

A VARIABLE-NAME should begin with the following, in the following instances:
b for a byte-type variable, e.g. bNum is a legal variable name
bo for a Boolean type variable, e.g. boItWas
w for a word type variable, e.g. wNum
s for string type variables. (They aren't available, as such, in Pascalite, but you'll often use them in other Pascals)
i for integer type variables (Also unavailable.)
r for real type variables (Also unavailable.)

The prefix is not required or enforced by Pascalite or other Pascals

Following the prefix, a VARIABLE-NAME consists of a NAME. I could go all long winded on you, and repeat what I said above about what a NAME can be, but I'll content myself with a few examples.

Legal VARIABLE-NAMEs:
bNumber
bMyProgram (a pretty unlikely name, but legal)
bSwitch2

Illegal VARIABLE-NAMEs:
bEgin (it is one of the reserved words)
bAn Illegal Name (has spaces)
bo27 (not actually illegal, but I wouldn't use it: part after prefix starts with a digit. Part after prefix is meant, in my keep-things-simple scheme, to be a NAME, which is supposed to start with a letter.)

Unwise VARIABLE-NAME:
MyNumber (didn't have prefix to identify data type)

The next word we need is STATEMENT. We won't be able to create an exhaustive definition of STATEMENT here without making things unwieldily... but we can go forward after describing some of the things that are legal STATEMENTs. Before we can do that, though, we need a few words that we can define exhaustively. to simplify that process, we're going to set aside the | punctuation mark to mean "or". (The Pascalite documentation uses / the way I'm using the |) As an example of the use of |, we'll define DIGIT exhaustively, though I suspect you already know what a digit is! We are also going to assign a special meaning to two colons appearing together. The definition is:

DIGIT:: 0|1|2|3|4|5|6|7|8|9

Nice and simple! (But then again, the meaning of "digit" is pretty simple, too.) By our rule:

Allowed digits: 5 or 2 or 7

Not digits: 23, 555, xyz

Now that we have defined a digit, we could define simple non-negative integer numbers as follows, once we reserve one last set of punctuation marks. [ and ] will be used to enclose optional parts of a definition. I'm going to call simple non-negative integer numbers SNNINs.

SNNIN::DIGIT | SNNIN[DIGIT]

Now... that's really cool, and I'll tell you why. The first thing after the :: says that 3 is a perfectly legal SNNIN, or 2, or 8, or any other digit. The magic is in the second alternative in the SNNIN's definition. It says that a SNNIN can be any SNNIN (e.g.3) with a digit tacked on. Now 37 becomes a legal SNNIN. As 37 is a legal SNNIN, so too is 370... and so on. Cool?

Applying the same logic to the idea of what a legal NAME is, we could say

NAME::LETTER | NAME LETTER | NAME DIGIT

and VARIABLE-NAME (written over several lines for clarity, and leaving out the ones not allowed in Pascalite.)

VARIABLE-NAME::

b NAME |

bo NAME |

w NAME

We need a few more words....

A BYTE will be a NUMBER equal to 0 or 255 or anything in between. (NB: No fractions allowed.)

A DESTINATION will be lcd, counter, porta, portb or portc. There are other legal destinations, but this is only an introduction, remember!

A STRING is any characters enclosed in 's, e.g. 'Hi' is a string.

Now that we have a few building blocks available, we can go back to talking about what a STATEMENT is.

STATEMENT::

VARIABLE-NAME := BYTE |

VARIABLE-NAME := VARIABLE-NAME |

write(DESTINATION,BYTE|STRING|VARIABLE-NAME)

From those cases of legal STATEMENTs, we are allowed the following:
bTmp:=23
bNum:=bTmp
write(lcd,'hi')

Look closely at the last definition. It also allows all of the following....
write(lcd,23)
write(portb,23)
write(portb,bTmp)
write(counter,'hi')

Don't you wish it were a perfect, simple, fair world? That last one is allowed, the program will run... it just won't do anything. It would be nice if we got some sort of error message. While it may be true that "Common sense isn't", and that with computers life is a little tidier than in the real world, you still have to bring some common sense to the keyboard. write(counter,3) works just fine. You just can't use a string with write when the destination is counter. There are rigorous ways of saying that... but you don't want to see them!

Now... more "fun": The following is true, and important:

COMPOUND-STATEMENT::
STATEMENT ; STATEMENT |
STATEMENT ; COMPOUND-STATEMENT

So, the following are legal COMPOUND-STATEMENTs:

bTmp:=23;bNum:=bTmp;

write(lcd,'hi');write(lcd,23)

Remembering that you can start new lines pretty well where you like in Pascal should be enough to make you comfortable with the idea that the two (not 4) COMPOUND-STATEMENTs above can be written as follows...

First COMPOUND-STATEMENT:

bTmp:=23;
bNum:=bTmp;

Second COMPOUND-STATEMENT:

write(lcd,'hi');
write(lcd,23)

The rules also allow the following as a COMPOUND-STATEMENT, don't they?

bTmp:=23;
bNum:=bTmp;
write(lcd,'hi');
write(lcd,23)

Let's think a little more about the good old semi-colon. It always causes beginners some hassle. Before you've been programming in Pascal for very long, you tend to stick one on the end of every line. The main place you must NOT put one in is just before an "else". While putting one on the end of the previous line is only human, it misunderstands what the semicolon is for. This brings me to my next important element of Pascal: the BLOCK. (I'll explain why there's no semicolon before an else in a minute.)

BLOCK::
STATEMENT |
begin STATEMENT ; end |
begin COMPOUND-STATEMENT ; end

The semicolon before the word end is unfortunate, but seems to be required by Pascalite, even though not all Pascals require one there. Not a big deal, but it introduces a tedious exceptional use of the semicolon. All other semicolons should be seen as "glue" between simple statements, (or between declarations... more on them later,) which are being turned into a block with a "begin" and an "end". The word "begin" is not a statement, so there's no semicolon after it. The following...

if boTmp then DoThis else DoThat

... is just a simple statement. That's why there's no semicolon after DoThis. It would split the simple statement into two incomplete parts, like putting a period (full stop) somewhere within "The quick fox ate the slow mouse", e.g. "The quick. Fox ate the slow mouse.".

The formal rule for the "if" statement:

IF-STMT:: if then BLOCK | if then BLOCK else BLOCK

To be thorough, I need to add here that a statement can be nothing. Because that is true, it is legal, if odd, to write something like...

if 4=5 then begin end else bTmp:=4;

While such a line would be odd in a finished program, you might want to have one like it for a while during the development of some program.

Now we have enough stuff to give a better, if still incomplete, definition of a Pascal program:

PROGRAM::program NAME ; BLOCK .

(Don't miss the period (full stop) at the end of the previous line.)

From what we have so far, we can say that the following are legal programs. I've put the exceptional semicolon on it's own line to show it's oddness, but it would usually just lurk on the end of the line before the "end".

program LittlePrgm;
begin
write(lcd,'Hi')
;
end.

==============

program LongerPrgm;
begin
write(lcd,'hi');
write(counter,2);
write(lcd,'bye')
;
end.

Okay so far? Make a cup of coffee.

It is now time to expand our list of allowed STATEMENTs, but first we need to define EXPRESSIONs in general, and define some types of EXPRESSION.

Again, we're not going to try to achieve a rigorous definition of EXPRESSION, but rather to rely on examples. EXPRESSIONs are the things that I often refer to as "boiling down" to a single value. E.g. "3+4" "boils down" to seven. If you had a variable bNum with 3 in it, I hope you don't have trouble seeing bNum+4 as another expression that boils down to seven. For the purposes of describing what is allowed in the language, we would also include 7 as an EXPRESSION even though the "boiling down" has already happened.

The expressions we've had so far are NUMERIC-EXPRESSIONS because they boil down to a number. The other important EXPRESSION class we need to worry about is the BOOLEAN-EXPRESSIONs. 4=5 is one that we've used repeatedly. Remember that "=" on its own is asking a question... "Are the things either side of me the same?" As 4 is not the same as 5, 4=5 boils down to "false". If boTmp had "true" in it, and boOther also had "true" in it, then "boTmp and boOther" would be a BOOLEAN-EXPRESSION which boiled down to true.

Armed with the above, we can add the following things to our catalogue of statements:

ASSIGNMENT::VARIABLE-NAME := EXPRESSION

The above allows:

bTmp:=5

boTmp:=boOther

bTmp:=bOther*5

Some more valid statements:

repeat BLOCK until BOOLEAN-EXPRESSION

The above allows the following, which would normally be written over several lines, and in many cases require some preceding code if they are to work sensibly....

repeat write(lcd,b0) until 4=5

repeat bTmp:=bTmp+2; write(lcd,bTmp) until bTmp>10

Then there's the for.. next loop:

for VARIABLE-NAME := EXPRESSION to EXPRESSION do BLOCK

This is a good moment to point out that just because something is "legal Pascal" does not mean that it is going work... there are other reasons for failure. A "for" loop is supposed to do something a number of times, and then allow program execution to pass onward. However, if you wrote...

for bTmp:=4 to 2 do write(lcd,'Hi');

... I don't know what you'd expect, but what you'd get would be no executions of the write(lcd,'Hi'); The test for leaving the loop would have been satisfied before you ever executed the statement after the "do".

Another sensible statement is....
if EXPRESSION then BLOCK [else BLOCK]

The last thing we have to consider is DECLARATIONS. Then we can come back to what a program is.

First we need to be explicit about something we've assumed earlier:

VARIABLE-TYPE::
byte|string|word|ARRAY-SPEC

"What's that ARRAY-SPEC?" you should be asking. (It hasn't been defined.) In the ARRAY-SPEC rule, the [ and ] do NOT mark an optional part. See examples.

ARRAY-SPEC::
array [NUMBER..NUMBER] of VARIABLE-TYPE

So. Allowed,, in theory: array [0..3] of byte;
or array [5000..6000000] of string;

But.. for good reasons.. Pascalite limits you to arrays of type byte, and the two numbers must both be bytes, i.e. no bigger than 255. Other Pasals allow you bigger and fancier arrays.

Now for DECLARATIONS. We'll be building up these rules up in layers. The outermost layer is DECLARATIONS, and DECLARATIONS consists of one or more of the following, separated by semicolons:

VAR-DECL
CONST-DECL
PROC-DECL
FUNC-DECL

Before we can define VAR-DECL, we need VDEC-PHRASE. And to define that, we're going to introduce another punctuation convention, built on the convention which says that tmp[DIGIT] means "tmp" or "tmp1" or "tmp9" are allowed. The new punctuation will use double square brackets, and mean "none or one or more of the enclosed MAY appear", so tmp[[digit]] would allow "tmp", "tmp1", "tmp428", etc.

We need a rule which allows things like "tmp", "tmp,fred,another", "t1,t2,t3,t4", etc. Getting the rule just right is tricky, if you are going to express the fact that if there are several items in the list, then you have commas between them, but no comma after the last, and no comma if there is only one item in the list. But it can be done! To allow "4", or "5,1", or "6,3,9", you could have the following rule:

RULE::
DIGIT |
DIGIT[[,DIGIT]]

I hope that makes sense, 'cause we're just about to use that punctuation convention to move ahead with our rules for Pascal!

VDEC-PHRASE::
VARIABLE-NAME |
VARIABLE-NAME [[, VARIABLE-NAME]]

So. Allowed VDEC-PHRASES:
bTmp
bTmp,btmp2,bAnotherVariable

Now we can define

VAR-DECL::
var
VDEC-PHRASE : VARIABLE-TYPE |
VDEC-PHRASE : VARIABLE-TYPE [[;VDEC-PHRASE : VARIABLE-TYPE]]

So. Allowed VAR-DECLs:

var bTmp:byte

or...

var bTmp,btmp2,bAnotherVariable:byte;

or...

var bTmp,btmp2,bAnotherVariable:byte;
    boIsOn:boolean;

By the way: The rules we have, and Pascal, allow the following...

var bTmp:word

... but it would be a bad idea. The prefix ("b" in this case) is supposed to help you remember what type of data goes in that variable. While not illegal, it makes no sense to name a word-type variable "bTmp".

I use the prefix "ba" on the name for any array of bytes, i.e. Byte Array.

Now for CONST-DECLs. Constants are a bit like variables... it's just that they don't vary! If you were working on a program that calculated taxes, and if the tax rate were 17 percent, it would be wise to declare a constant called "tax". Thereafter, anyplace you needed the 17, you would simply say "tax". Two reasons: If the tax rate changes, you only need to change the line which made "tax" stand for 17. the other reason is that it makes your program easier to understand when you are reading it.

To declare one or more constants, you use the word "const", followed by the name of the first constant, followed by the equals sign ( the ":=" assignment operator would have been more logical, but it is the equals sign that is used. If you have several constants to declare, you then supply a semicolon, the next constant name, the equals sign again, the value for that constant, and so on. Semi colons BETWEEN items in the list, e.g.

const tax=17;max=100;min=0

That definition-by-example pretty well says it all, but just for comparison, here's a systematic definition of a CONST-DECL. First we need....

VALUE::
NUMBER | STRING

Then we need...

CONST-PHRASE::
VARIABLE-NAME=VALUE

... and now we can finish with

CONST-DECL::
CONST-PHRASE |
CONST-PHRASE [[;CONST-PHRASE]]

Next, we come to the PROC-DECL.

HERE BEGINNETH A CHUNK THAT IS NOT YET QUITE PERFECT... SORRY...GIVE IT A READ, BUT DON'T BE TOO ALARMED BY PUZZLES. EMAIL ME AND I MIGHT GET CRACKING ON POLISHING IT UP! I'VE MARKED THE END OF THE IFFY BIT

In order to use a user defined procedure, you must first say what it should do. This is called declaring it, and is done with a PROC-DECL. The rules for PROCEDURE-NAMEs are the same as for VARIABLE-NAMES.

A simple PROC-DECL would be:

procedure PROCEDURE-NAME ; BLOCK

(The block has to be more than a simple statement, i.e. it must start with "begin" and finish with "end".)

The more complex procedure declarations require the PARAM-DECLARATIONS too. The "what" will be explained in a minute. The where is....

procedure PROCEDURE-NAME PARAM-DECLARATIONS; BLOCK

PARAM-DECLARATIONS::

([var] VARIABLE-NAME [,VARIABLE-NAME...] : DATA-TYPE )

HERE ENDETH THE IFFY BIT

It has been a lot of work to reach this point... the payoff is that we can now say...

PASCAL-PROGRAM::
program NAME ;
[DECLARATIONS;]
BLOCK
.

That is an example of the splendid elegance that emerges from some programming topics. Would you credit that Pascal programs consisting of hundreds of lines of sourcecode could really, in essence, be as simple as that? They do!

Apologies for raining on your parade at this point, but I must just mention that even after your program obeys all of the above rules, it may still not do what you wanted.... but maybe you'll take some consolation in the fact that making your program obey the rules will at least bring it to the point where it might do what you wanted! (Until it obeys the rules, it won't even run!)

So... if it obeys the rules, how can it not do what you want? Think of learning to program as learning a language. If you went to a foreign land, and in their language said, with correct grammar and everything "I want an apple, please", would you consider your "program" to be working if what you'd meant to say was "I want an orange"? Just because what you've said is correct in the language, be it a human language or a computer's language, doesn't insure that you've said what you meant to say!

To search THIS site.... (Go to the site's above, and use their search buttons if you want to search them.)... Way to search this site without using forms

� Site search Web search

Ad from page's editor: Yes.. I do enjoy compiling these things for you... hope they are helpful. However.. this doesn't pay my bills!!! If you find this stuff useful, (and you run an MS-DOS or Windows pc) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!

Click here to visit editor's freeware, shareware page.

Link to editor's (Arunet) homepage

How to email or write this page's editor, Tom Boyd