discusses the error diagnostics of the programs
is a simple but useful program which invokes
to do all the real processing.
and section 5.2 below for more details.
A few comments on the general nature of the syntax errors usually
made by Pascal programmers
and the recovery mechanisms of the current translator may help in using
Characters such as `$', `!', and `@' are not part of the language Pascal.
If they are found in the source program,
and are not part of a constant string, a constant character, or a comment,
they are considered to be
This can happen if you leave off an opening string quote `\(aa'.
Note that the character `"', although used in English to quote strings,
is not used to quote strings in Pascal.
Most non-printing characters in your input are also illegal except
in character constants and character strings.
Except for the tab and form feed characters,
which are used to ease formatting of the program,
non-printing characters in the input file print as the character `?'
so that they will show in your listing.
There is no character string of length 0 in Pascal.
Consequently the input `\(aa\(aa' is not acceptable.
Similarly, encountering an end-of-line after an opening string quote `\(aa'
without encountering the matching closing quote yields the diagnostic
``Unmatched \(aa for string''.
It is permissible to use the character `#'
to delimit character and constant strings for portability reasons.
For this reason, a spuriously placed `#' sometimes causes the diagnostic
Similarly, a `#' in column one is used when preparing programs which are to
be kept in multiple files.
See section 5.9 for details.
Comments in a comment, non-terminated comments
As we saw above, these errors are usually caused by leaving off a comment
You can convert parts of your program to comments
without generating this diagnostic
since there are two different kinds of comments \- those delimited by
`{' and `}', and those delimited by `(*' and `*)'.
{ This is a comment enclosing a piece of program
a := functioncall; (* comment within comment *)
lhs := rhs; (* another comment *)
By using one kind of comment exclusively in your program you can use
the other delimiters when you need to
parts of your program\*(dg.
\*(dgIf you wish to transport your program,
especially to the 6000-3.4 implementation,
you should use the character sequence `(*' to delimit comments.
For transportation over the
to Pascal 6000-3.4, the character `#' should be used to delimit characters
In this way you will also allow the translator to help by detecting
statements accidentally placed within comments.
If a comment does not terminate before the end of the input file,
the translator will point to the beginning of the comment,
indicating that the comment is not terminated.
In this case processing will terminate immediately.
See the discussion of ``QUIT'' below.
This part of the language is a minor nuisance.
Pascal requires digits in real numbers both before and after the decimal
Thus the following statements, which look quite reasonable to
users, generate diagnostics in Pascal:
These same constructs are also illegal as input to the Pascal interpreter
Replacements, insertions, and deletions
When a syntax error is encountered in the input text,
the parser invokes an error recovery procedure.
This procedure examines the input text immediately after the point
of error and considers a set of simple corrections to see whether they
will allow the analysis to continue.
These corrections involve replacing an input token with a different
or replacing an input token with a different token.
Most of these changes will not cause fatal syntax errors.
The exception is the insertion of or replacement with a symbol
such as an identifier or a number;
in this case the recovery makes no attempt to determine
number should be inserted,
hence these are considered fatal syntax errors.
Consider the following example.
The only surprise here may be that Pascal does not have an exponentiation
operator, hence the complaint about `**'.
This error illustrates that, if you assume that the language has a feature
which it does not, the translator diagnostic may not indicate this,
as the translator is unlikely to recognize the construct you supply.
Undefined or improper identifiers
If an identifier is encountered in the input but is undefined,
the error recovery will replace it with an identifier of the
Further references to this identifier will be summarized at the
if the reference occurred in the main program.
if an identifier is used in an inappropriate way,
identifier is used in an assignment statement,
a diagnostic will be produced and an identifier of the appropriate
Further incorrect references to this identifier will be flagged only
if they involve incorrect use in a different way,
with all incorrect uses being summarized in the same way as undefined
Expected symbols, malformed constructs
If none of the above mentioned corrections appear reasonable, the
error recovery will examine the input
to the left of the point of error to see if there is only one symbol
which can follow this input.
If this is the case, the recovery will print a diagnostic which
indicates that the given symbol was `Expected'.
In cases where none of these corrections resolve the problems
the recovery may issue a diagnostic that indicates that the
If necessary, the translator may then skip forward in the input to
a place where analysis can continue.
This process may cause some errors in the text to be missed.
Consider the following example:
style variable declaration
which the translator diagnosed as a `Malformed declaration'.
When, on line 6, we used `(' and `)' for subscripting
rather than the `[' and `]' which are used in Pascal,
the translator noted that
argument lists are delimited by parentheses in Pascal.
As it is not permissible to assign to procedure calls the translator
diagnosed a malformed statement at the point of assignment.
Expected and unexpected end-of-file, ``QUIT''
If the translator finds a complete program, but there is more non-comment text
in the input file, then it will indicate that an end-of-file was expected.
This situation may occur after a bracketing error, or if too many
are present in the input.
after the recovery says that it
since `.' is the symbol that terminates a program.
If severe errors in the input prohibit further processing
the translator may produce a diagnostic followed by ``QUIT''.
One example of this was given above \-
a non-terminated comment;
another example is a line which is longer than 160
Consider also the following example.
Translator semantic errors
The extremely large number of semantic diagnostic messages which the translator
produces make it unreasonable to discuss each message or group of messages
The messages are, however, very informative.
We will here explain the typical formats and the terminology used in the error
messages so that you will be able to make sense out of them.
In any case in which a diagnostic is not completely comprehensible you can
by Jensen and Wirth for examples.
Format of the error diagnostics
As we saw in the example program above, the error diagnostics from
the Pascal translator include the number of a line in the text of the program
as well as the text of the error message.
While this number is most often the line where the error occurred, it
is occasionally the number of a line containing a bracketing keyword
In this case, the diagnostic may refer to the previous statement.
This occurs because of the method the translator uses for sampling line
The absence of a trailing `;' in the previous statement causes the line
number corresponding to the
to become associated with the statement.
As Pascal is a free-format language, the line number associations
can only be approximate and may seem arbitrary to some users.
This is the only notable exception, however, to reasonable associations.
Since Pascal is a strongly typed language, many semantic errors manifest
themselves as type errors.
These are called `type clashes' by the translator.
The types allowed for various operators in the language are summarized on page
It is important to know that the Pascal translator, in its diagnostics,
distinguishes between the following type `classes':
array Boolean char file integer
pointer real record scalar string
These words are plugged into a great number of error messages.
Thus, if you tried to assign an
variable you would receive a diagnostic like the following:
In this case, one error produced a two line error message.
If the same error occurs more than once, the same explanatory
diagnostic will be given each time.
The only class whose meaning is not self-explanatory is
Scalar has a precise meaning in the
where, in fact, it refers to
types as well as the enumerated types.
For the purposes of the Pascal translator,
in an error message refers to a user-defined, enumerated
\*btype\fP color = (red, green, blue)
For integers, the more explicit denotation
Although it would be correct, in the context of the
to refer to an integer variable as a
prefers the more specific identification.
Function and procedure type errors
For built-in procedures and functions, two kinds of errors occur.
If the routines are called with the wrong number of arguments a message similar to:
If the type of the argument is wrong, a message like
A few functions and procedures implemented in Pascal 6000-3.4 are
diagnosed as unimplemented in
Pascal, notably those related to
Can't read and write scalars, etc.
The messages which state that scalar (user-defined) types
cannot be written to and from files are often mysterious.
It is in fact the case that if you define
\*btype\fP color = (red, green, blue)
the translator does not associate these constants with the strings
`red', `green', and `blue' in any way.
If you wish such an association to be made, you will have to write a routine
Note, in particular, that you can only read characters, integers and real
You cannot read strings or Booleans.
but the representation is binary rather than string.
The diagnostics for semantically ill-formed expressions are very explicit.
Consider this sample translation:
This example is admittedly far-fetched, but illustrates that the error
messages are sufficiently clear to allow easy determination of the
problem in the expressions.
Several diagnostics produced by the Pascal translator complain about
Pascal considers variables to have the same type only if they were
declared with the same constructed type or with the same type identifier.
do not have the same type.
thus produces the diagnostics:
Thus it is always necessary to declare a type such as
\*btype\fP intptr = ^ integer;
\*bvar\fP x: intptr; y: intptr;
Note that if we had initially declared
\*bvar\fP x, y: ^ integer;
then the assignment statement would have worked.
is allowed in either case.
type identifier rather than a constructed type,
it is always necessary, in practice,
to declare any type which will be used in this way.
Pascal flags unreachable statements.
Such statements usually correspond to errors in the program logic.
Note that a statement is considered to be reachable
if there is a potential path of control,
even if it can never be taken.
Thus, no diagnostic is produced for the statement:
\*bif\fP false \*bthen\fP
Goto's into structured statements
The translator detects and complains about
statements which transfer control into structured statements (\c
It does not allow such jumps, nor does it allow branching from the
Such checks are made only within the body of a single procedure or
Unused variables, never set variables
Pascal always clears variables to 0 at
good programming practice to rely on this initialization.
To discourage this practice, and to help detect errors in program logic,
flags as a `w' warning error:
Use of a variable which is never assigned a value.
A variable which is declared but never used, distinguishing
between those variables for which values are computed but which are never
used, and those completely unused.
In fact, these diagnostics are applied to all declared items.
which is declared but never used is flagged.
may be used to suppress these warnings;
see sections 5.1 and 5.2.
Translator panics, i/o errors
One class of error which rarely occurs, but which causes termination
of all processing when it does is a panic.
A panic indicates a translator-detected internal inconsistency.
A typical panic message is:
snark (rvalue) line=110 yyline=109
If you receive such a message, the translation will be quickly and perhaps
You should contact a teaching assistant or a member of the system staff,
after saving a copy of your program for later inspection.
If you were making changes to an existing program when the problem
be able to work around the problem by ascertaining which change caused the
and making a different change or correcting an error in the program.
You should report the problem in any case.
Pascal system bugs cannot be fixed unless they are reported.
The only other error which will abort translation when no errors are
detected is running out of memory.
All tables in the translator, with the exception of the parse stack,
are dynamically allocated, and can grow to take up the full available
process space of 64000 bytes.
Generally, the size of the largest translatable program is directly related to
A number of non-trivial Pascal programs, including
some with more than 2000 lines and 2500 statements
have been translated and interpreted using
Notable among these are the Pascal-S
a large set of programs for automated generation of
and a general context-free parsing program which has been used to
parse sentences with a grammar for a superset of English.
If you receive an out of space message from the translator
during translation of a large
or one containing a large number of string constants
to translate your program if you break this one
Other errors which you may encounter when running
cannot open the file you specify,
If your disk space quota\*(dg is exceeded while
or if the system runs out of disk space you will be notified;
in this case you should remove unneeded files.
\*(dgDisk quotas are also a modification at Berkeley
and may not exist at your installation.
We saw, in our second example, a run-time error.
We here give the general description of run-time errors.
The more unusual interpreter error messages are explained
briefly in the manual section for
These errors occur when the object file to be executed is not available
Typical errors here are caused by the specified object file not existing,
not being a Pascal object, or being inaccessible to the user.
These errors occur when the program interacts with the Pascal runtime
environment in an inappropriate way.
Typical errors are values or subscripts out of range,
bad arguments to built-in functions,
exceeding the statement limit because of an infinite loop,
or running out of memory\*(dd.
\*(ddThe checks for running out of memory are not foolproof and there
is a chance that the interpreter will fault, producing a core image
when it runs out of memory.
This situation occurs very rarely.
The interpreter will produce a backtrace after the error occurs,
showing all the active routine calls,
option was disabled when the program was translated.
Unfortunately, no variable values are given and no way of extracting them
As an example of such an error, assume that we have accidentally
on line 2 of the program primes as given in section 2.6 above.
If we run this program we get the following response.
Here the interpreter indicates that the program terminated
abnormally due to a subscript out of range near line 14,
which is eight lines into the body of the program primes.
If the program is interrupted while executing
option was not specified,
then a backtrace will be printed.\*(dg
\*(dgOccasionally, the Pascal system will be in an inconsistent
e.g. when an interrupt terminates a
In this case, the backtrace will only contain the current line.
A reverse call order list of procedures will not be given.
of profile information will be written if the program was translated
The final class of interpreter errors results from inappropriate
interactions with files, including the user's terminal.
Included here are bad formats for integer and real numbers (such as
no digits after the decimal point) when reading.
A small number of panics are possible with
These should be reported to a teaching assistant or to the system