Error reporting, etc.

[Bruce Lilly]

I've seen much of the recent discussion, and there are a
few points which I would like to raise:

1. Tools, not solutions. Flex, lex, Bison, and yacc are
   at their best when they are tools that do a specific
   job and do it well.  They necessarily cannot be all
   things to all users.  Bells and whistles may be nice
   when they're desired, but please make sure that they
   can be turned off when they are not wanted.

2. The details of the application determine the nature
   of error reporting.  In some cases "lines" are of no
   interest, either because the input consists of "records"
   rather than "lines" or because errors are reported
   in context and need not reference line numbers. Even
   when lines are of interest, the definition of a line
   varies depending on the application; for example in
   Internet text messages, lines are delimited by a CRLF
   pair, and a '\n' not immediately preceded by '\r' is
   either an error or just some raw data (so "looking for
  '\n' chars" will be wrong).

3. Scalability and flexibility matter.  "Rescan the input"
   may work fine for a 30 kB disk file, but it won't work
   for interactive use and is impractical for a 10 GB
   stream.

4. Parser/lexical analyzer interface and coupling. Some
   applications require that the lexical analyzer start
   condition (for example) be changed depending on state
   information only available in the parser. Stating that
   they "should be completely separate" is too dogmatic.
   There are other reasons why the parser and lexical
   analyzer may need rather tight coupling; for example
   a reentrant lexical analyzer requires that state
   information be retained in the parser between calls to
   the lexical analyzer.

The effort apparently being put into error reporting which
must necessarily vary depending on the application could 
probably be better spent on more generally useful changes.

-- 
Bruce Lilly