Re: error reporting, was language design implications

Gene Wirchenko <genew@ocis.net>
Wed, 19 Jan 2011 11:11:42 -0800

          From comp.compilers

Related articles
[3 earlier articles]
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-12)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-13)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-14)
Re: language design implications for variant records in a pascal-like genew@ocis.net (Gene Wirchenko) (2011-01-17)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (2011-01-18)
Re: error reporting, was language design implications genew@ocis.net (Gene Wirchenko) (2011-01-19)
| List of all articles for this month |
From: Gene Wirchenko <genew@ocis.net>
Newsgroups: comp.compilers
Date: Wed, 19 Jan 2011 11:11:42 -0800
Organization: A noiseless patient Spider
References: 10-12-040 10-12-043 11-01-005 11-01-025 11-01-038 11-01-041 11-01-049 11-01-072 11-01-080
Keywords: errors, syntax, design
Posted-Date: 21 Jan 2011 22:09:06 EST

On Tue, 18 Jan 2011 14:20:45 +0000, Martin Rodgers
<mcr@wildcard.demon.co.uk> wrote:


[snip]


>We could probably ask similar questions about compilers...Error reporting
>and recovery has always fascinated me, probably because I was frequently
>frustrated by the unhelpfulness of the error msgs given by so many tools.


          You, too? I used to like reading the appendix of error messages
for a compiler. Philosophy of the compiler.


>My first lexer buffered text at the line level and counted the
>characters and lines read so far, then provided them to the error
>reporting code so that the line number and the line itself could be
>given to the user, along with a '^' under the character at which the
>error was detected.


          Well, I like this sort of thing. It makes it much easier for me
to find the error. An ugly counterexample: SQL statements can get
very long, and it can make non-specific error messages not very useful
and occasionally quite frustrating.


[snip]


Sincerely,


Gene Wirchenko



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.