Re: GCC for BCPL

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

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