Tom Crick <tc@cs.bath.ac.uk> wrote:>...a re-evaluation of using Bison to create the parser. The>original BCPL parsers were recursive-descent and certain language>features (particularly the optional semicolon problem) seem to point>towards their use now...

As a (non-BCPL) data point on this, in "The Design and Evolution of C++",
Bjarne Stroustrup comments (p. 68):

In 1982 when I first planned Cfront [the preprocessor from C++ to C],
I wanted to use a recursive descent parser because I had experience
writing and maintaining such a beast, because I liked such parsers'
ability to produce good error messages, and because I liked the idea
of having the full power of a general-purpose programming language
available when decisions had to be made in the parser. However, being
a conscientious young computer scientist I asked the experts. Al Aho
and Steve Johnson were in the Computer Science Research Center and
they, primarily Steve, convinced me that writing a parser by hand was
most old-fashioned, would be an inefficient use of my time, would
almost certainly result in a hard-to-understand and hard-to-maintain
parser, and would be prone to unsystematic and therefore unreliable
error recovery. The right way was to use an LALR(1) parser generator,
so I used Al and Steve's YACC.

For most projects, it would have been the right choice. For almost
every project writing an experimental language from scratch, it would
have been the right choice. For most people, it would have been the
right choice. In retrospect, for me and C++ it was a bad mistake.

He was dealing with much the same situation: C was originally designed
for recursive descent, and fitting it into LALR(1) wasn't easy. PCC
had a yacc parser for C, but in fact it wasn't right: it handled some
of the more obscure cases, later significant in C++, incorrectly. An
LALR(1) grammar for C eventually appeared as part of the ANSI C work,
too late. There have been repeated LALR(1) problems as C++ has
evolved.
--
"Think outside the box -- the box isn't our friend." | Henry Spencer
-- George Herbert | henry@spsystems.net