|Top Previous Next|
There are some errors that seem to catch everyone when they first start programming in XPL0. Here is a list of these errors beginning with the most common.
1. Mismatched Pairs. There are several commands or symbols that must be used in pairs. Many newtimers omit one of the pairs. The most likely place that you might do this is with "begin-end"s. It is easy to get the wrong number of "end"s at the end of a complex procedure. The easiest way to keep track of these is to use indentation:
. . .
. . .
. . .
Each indentation must have a "begin" and a corresponding "end".
Here are some other pairs to watch for:
" . . . " Double quotes around text strings
( . . . ) Parentheses
[ . . . ] Brackets (same as "begin-end"s)
\ . . . \ Comments (when not the last item on the line)
2. Semicolon Issues. A semicolon can catch you in two ways. One is that there must be a semicolon between all statements in the program. The other is that you must not place a semicolon before the "else" of an "if" statement or the "other" of a "case" statement. For example:
if N = Guess then
end <---------- semicolon is illegal here
N:= N + 1; <----- semicolon is required here
Restart; <------- semicolon is optional here
3. Intrinsic Arguments. Intrinsics require various numbers of arguments. A common error is to pass the wrong number of arguments or the wrong type of arguments (integer versus real). This causes a stack imbalance and your program blows up.
Text("message"); Text(0, "message");
ChIn(0); I:= ChIn(0);
I:= ChOut(0,^A); ChOut(0, ^A);
X:= Sqrt(100); X:= Sqrt(100.);
4. Procedure Arguments. When arguments are passed to a procedure, the values passed are stored into the first variables declared and in the same order that they are passed. As a program is written, it is easy to add new variables to the declarations, which shift their order and change which arguments are passed into which variables. "Integer", "real", and "character" declarations can be mixed in any way necessary to properly pass values into the correct variables. It is often useful to have completely separate declarations for arguments and local variables. For example:
procedure Oink(I, X, Ch);
integer I; \Arguments
integer A, B, C; \Local variables
. . .
5. Array Bounds. XPL0 does not do run-time array bounds checking. Thus it is possible to store something in an incorrect place in memory. Almost always, this is due to an error in the calculation of a subscript for an array.
6. Local And Global Names. Avoid using the same name both locally and globally. You can easily get confused as to which is which, and this can be a difficult error to find. If you use a local variable with the same name as a global variable, the compiler does not give a NAME ALREADY DECLARED error; the local variable is used instead of the global variable. As a consequence you should make global names longer and more formal than local names. For example, avoid using a name like "I" for a global. At the very least call it "II".