Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #6953
| From | BartC <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: Parsing and reporting errors? |
| Date | 2016-09-30 18:09 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <nsm68a$bvv$1@dont-email.me> (permalink) |
| References | <reporting-20160930143708@ram.dialup.fu-berlin.de> |
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
Back to comp.programming | Previous | Next | Find similar | Unroll thread
Re: Parsing and reporting errors? BartC <bc@freeuk.com> - 2016-09-30 18:09 +0100
csiph-web