Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6953 > unrolled thread

Re: Parsing and reporting errors?

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Parsing and reporting errors? BartC <bc@freeuk.com> - 2016-09-30 18:09 +0100

#6953 — Re: Parsing and reporting errors?

On 30/09/2016 14:51, Stefan Ram wrote:
>   A parser (syntactical analyser) gets tokens from the scanner
>   (lexical analyser), which gets characters from a character source.
>   (In terms of OOP, each of these, the parser, the scanner and
>   the character source might be an individual object.)
>
>   It might happen that the parser detects a syntax error.
>   How can it then report this?
>
>   Ok, it might print the token and a diagnostic message.
>
>   But the parser does not know the line and the offset in the
>   line, so it can't print the line number and source context.
>   This has already been abstracted away by the lower entities
>   (the scanner and the character source). Usually, the parser
>   does not need to know these lower-level details.
>
>   How does one usually deal with this? (Printing the line number,
>   the line offset and the region of the source code where the
>   error was detected when the parser detects an error)

>   My first idea was to decorate each and every token with
>   such context information that can be used in the case
>   of an error, so that the parser then can access it.

That's what I use: each token is returned as a bunch of information ( a 
struct) including the line number and file number.

>   So, when the parser detects an erroneous token,
>   it would get the line number and line offset of the token
>   from this token itself and then incorporate it in the error
>   message.
>
>   Another idea was that the parser can "pass down"
>   a call to the scanner to ask it to print an error
>   message adding the context (which the scanner in
>   turn might pass down to the character source).

One scanner I used had an independent pass done before any parsing. By 
the time a parse error is detected, it will have long since reached the 
end of the file. (Here, it created a big list of token structs with line 
info in each one. Lookahead was very easy.)

But the idea can work otherwise: if the extra info isn't supplied in the 
token in a form the parser can grab for itself (I naughtily use globals 
for this), then a function within the scanner can pick it up instead.

>   So, in this case, when the parser would detect an
>   erroneous token, it would ask the scanner to print
>   a message indicating the "current position"
>   (line number and line offset) of the scanner.
>
>   However, due to "lookahead" or some "buffering",
>   the current position of the scanner might already
>   be ahead of that current token of the parser.

That's going to be a problem anyway, as an error might be detected in 
any of multiple tokens making up a construct, or when it sees the end. 
The line number of which token should be used? For example, the closing 
"}" is missing in the construct "if (...) {...}" which is spread over a 
dozen lines. It would be more helpful to report the position of the 
initial "if" or "{" than of the non-existent end of the block.

In the case of undefined names, you might want to report the location of 
a reference to the name, but you might not know it's undefined until the 
end of the source file.

-- 
Bartc

[toc] | [standalone]

Back to top | Article view | comp.programming

csiph-web