NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/cplus/13472

Text File | 1992-09-10 | 4.3 KB | 95 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!decwrl!concert!sas!mozart.unx.sas.com!sasghm
From: [e-mail] (Gary Merrill)
Subject: Re: C++ Grammar
Originator: [e-mail]
Sender: [e-mail] (Noter of Newsworthy Events)
Message-ID: <[e-mail]>
Date: Thu, 10 Sep 1992 14:29:56 GMT
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: theseus.unx.sas.com
Organization: SAS Institute Inc.
Lines: 81


In article <[e-mail]>, [e-mail] (Matthew Watson) writes:
|> [e-mail] (Kevin T. Boyle) writes:
|>
|>
|>
|> >        I am interested in writing a syntax parser for C++ and
|> >    I wonder if anyone has a YACC compatible grammar that they
|> >    could supply me.  Your help would be very appreciated.
|> There is a grammar available at the same place you get c++-mode for emacs
|> from, ftp.cme.nist.gov:pub/gnu/?? I think. Sorry if this isn't right but
|> I know there is one out there. Try using archie.
|> --
|>
|> -------------------------------------------------------------------------------
|>      -  Matthew Watson -         | MHSnet: [e-mail]
|>      Australian and Overseas       |

There have been enough requests of this sort that someone ought to
emphasize a couple of important points.  In a significant sense,
the concept of a yacc compatible grammar for C++ is incoherent.
I take it that what most people mean by this is "A grammar like
the ones you see in the various C++ books that I could run yacc on."
My impression is that most people think this is like asking for
a yaccable C grammar.

But the syntax of C++ is quite different in various places from the
syntax of C.  Note that in _The_Annotated_C++_Reference_Manual_ it
is remarked that

    The general cases cannot be resolved without backtracking,
    nested grammars or similar advanced parsing strategies.

The point is that the grammars you will find that *look* like
yacc grammars for C++ are not LR(k) for any k.  You can write
a yaccable grammar that *looks* like a grammar for C++, but yacc
won't (can't) generate a correct C++ parser from it.  An LALR(1)
parser generator will not create for you a parser capable of
parsing a grammar that is not LR(k).

Now a disclaimer for the record (and for obvious legal reasons).
I have not looked at the yacc grammar for g++.  I have not seen
the C++ yacc grammar developed by Roskind.  However, ...

If you noticed a prior posting of mine concerning how various
C++ compilers handle syntactic ambiguities in C++ you will have
noticed that g++ does not do well at all.  Since their parser
is a yacc parser this is not surprising.  If you use a grammar
similar to this, you will be able to parse a language that is
*close* to C++ in a lot of respects, but this language is *not*
C++.

Roskind has apparently constructed a truly yaccable C++ grammar.
I believe I know how this was done and considered doing it myself,
but rejected the approach for several reasons.  If I am correct,
you would discover that the grammar differs in some significant
respects from what you are thinking of as a C++ grammar.  There
was a posting a while ago on comp.compilers that confirms this
hypothesis (from someone who has seen and used the grammar).  I
suggest you look at that posting.

The grammar we use for our C++ compiler is a yacc grammar, and
we use a version of yacc to generate the parser -- sort of.  I have
made several modifications to yacc to facilitate the parsing of
C++ and of course the resulting yacc parser *still* does not
parse C++ (remember, it *can't*).  We successfully parse C++
by using backtracking (or maybe it's "advanced parsing strategies"
-- depends on your point of view).  To see how this is done
with a recursive descent parser see the article by Mike Ball from
Taumetric in the latest _C++_Report_.

Apparently a number of people are getting interested in writing
various tools for C++ (Editors that do syntax checking, for
example?  Software metrics?) and feel that a good and easy place
to start would be from a yacc parser for C++.  Good luck.


--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / [phone]
[e-mail] ... !mcnc!sas!sasghm