puman3.n

早期freebsd实现

.\" Copyright (c) 1980, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)puman3.n	8.1 (Berkeley) 6/8/93
.\"
.if !\n(xx \{\
.so tmac.p \}
.if n 'ND
.nr H1 2
.NH
Error diagnostics
.PP
This section of the
.UM
discusses the error diagnostics of the programs
.PI ,
.PC
and
.X .
.I Pix
is a simple but useful program which invokes
.PI
and
.X
to do all the real processing.
See its manual section
.IX
(1)
and section 5.2 below for more details.
All the diagnostics given by
.PI
will also be given by
.PC .
.NH 2
Translator syntax errors
.PP
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
the system.
.SH
Illegal characters
.PP
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
`illegal characters'.
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.
.SH
String errors
.PP
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 `#'
instead of `\''
to delimit character and constant strings for portability reasons.
For this reason, a spuriously placed `#' sometimes causes the diagnostic
about unbalanced quotes.
Similarly, a `#' in column one is used when preparing programs which are to
be kept in multiple files.
See section 5.11 for details.
.SH
Comments in a comment, non-terminated comments
.PP
As we saw above, these errors are usually caused by leaving off a comment
delimiter.
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 `*)'.
Thus consider:
.LS
{ This is a comment enclosing a piece of program
a := functioncall;	(* comment within comment *)
procedurecall;
lhs := rhs;		(* another comment *)
}
.LE
.PP
By using one kind of comment exclusively in your program you can use
the other delimiters when you need to
``comment out''
parts of your program\*(dg.
.FS
\*(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
.I rcslink
to Pascal 6000-3.4, the character `#' should be used to delimit characters
and constant strings.
.FE
In this way you will also allow the translator to help by detecting
statements accidentally placed within comments.
.PP
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.
.SH
Digits in numbers
.PP
This part of the language is a minor nuisance.
Pascal requires digits in real numbers both before and after the decimal
point.
Thus the following statements, which look quite reasonable to
.SM
FORTRAN
.NL
users, generate diagnostics in Pascal:
.LS
.so digitsout
.LE
These same constructs are also illegal as input to the Pascal interpreter
.I px .
.SH
Replacements, insertions, and deletions
.PP
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
token,
inserting a token,
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
.I which
identifier or
.I what 
number should be inserted,
hence these are considered fatal syntax errors.
.PP
Consider the following example.
.LS
% \*bpix -l synerr.p\fR
.tr --
.so synerrout
%
.LE
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.
.SH
Undefined or improper identifiers
.PP
If an identifier is encountered in the input but is undefined,
the error recovery will replace it with an identifier of the
appropriate class.
Further references to this identifier will be summarized at the
end of the containing
.B procedure
or
.B function
or at the end of the
.B program
if the reference occurred in the main program.
Similarly,
if an identifier is used in an inappropriate way,
e.g. if a
.B type
identifier is used in an assignment statement,
or if a simple variable
is used where a
.B record
variable is required,
a diagnostic will be produced and an identifier of the appropriate
type inserted.
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
variable uses are.
.SH
Expected symbols, malformed constructs
.PP
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'.
.PP
In cases where none of these corrections resolve the problems
in the input,
the recovery may issue a diagnostic that indicates that the
input is ``malformed''.
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.
.PP
Consider the following example:
.LS
% \*bpix -l synerr2.p\fR
.so synerr2out
%
.LE
Here we misspelled
.I output
and gave a
.SM FORTRAN
style variable declaration
which the translator diagnosed as a `Malformed declaration'.
When, on line 6, we used `(' and `)' for subscripting
(as in
.SM FORTRAN )
rather than the `[' and `]' which are used in Pascal,
the translator noted that
.I a
was not defined as a
.B procedure .
This occurred because
.B procedure
and
.B function
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.
.SH
Expected and unexpected end-of-file, ``QUIT''
.PP
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
.B end s
are present in the input.
The message may appear
after the recovery says that it
``Expected \`.\'\|''
since `.' is the symbol that terminates a program.
.PP
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
characters.
Consider also the following example.
.LS
% \*bpix -l mism.p\fR
.so mismout
%
.LE
.NH 2
Translator semantic errors
.PP
The extremely large number of semantic diagnostic messages which the translator
produces make it unreasonable to discuss each message or group of messages
in detail.
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
refer to the
.I "User Manual"
by Jensen and Wirth for examples.
.SH
Format of the error diagnostics
.PP
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
like
.B end
or
.B until .
In this case, the diagnostic may refer to the previous statement.
This occurs because of the method the translator uses for sampling line
numbers.
The absence of a trailing `;' in the previous statement causes the line
number corresponding to the
.B end
or
.B until .
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.
.SH
Incompatible types
.PP
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
108 of the
Jensen-Wirth
.I "User Manual" .
It is important to know that the Pascal translator, in its diagnostics,
distinguishes between the following type `classes':
.br
.ne 8
.TS
center;
lew(10) le le le le.
array	Boolean	char	file	integer
pointer	real	record	scalar	string
.TE
These words are plugged into a great number of error messages.
Thus, if you tried to assign an
.I integer
value to a
.I char
variable you would receive a diagnostic like the following:
.LS
.so clashout
.LE
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.
.SH
Scalar
.PP
The only class whose meaning is not self-explanatory is 
`scalar'.
Scalar has a precise meaning in the
Jensen-Wirth
.I "User Manual"
where, in fact, it refers to
.I char ,
.I integer ,
.I real ,
and
.I Boolean
types as well as the enumerated types.
For the purposes of the Pascal translator,
scalar
in an error message refers to a user-defined, enumerated
type, such as