Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!bs
From: bs@alice.UUCP (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: zortech problem with lex
Summary: LALR parsing
Message-ID: <10541@alice.UUCP>
Date: 2 Mar 90 02:45:30 GMT
References: <6300008@ux1.cso.uiuc.edu> <24800002@sunb6> <25ECE752.29589@paris.ics.uci.edu>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 46




Ron Guilmette (our resident C++ Entomologist) writes:

 > So the goal is good.  What is *not* good is muddling the issue with meaningless
 > catch phrases like "C++ is not LALR(1)".  In order to move the discussion onto
 > a higher plain,  let's try to be accurate and just say that it would be nice
 > if an LALR(1) grammar for C++ could allow for much more disambiguation via
 > easy-to-implement LALR(1) syntax rules.

 > >What Bjarne probably meant (judging from the cfront 2.0
 > >sources) is that he was using the LALR(1) parser generated by yacc to
 > >recognize C++.

Exactly. Plus an oversmart ``lexical'' analyser.

 > Free advice:  Second guessing Bjarne's intended meaning based on sketchy
 > second-hand accounts is probably inadvisable.

Very nice advice. There can be no simple LALR(1) parser for C++.
The reason is examples like:

	// let T be some type

	f()
	{
		T (*p)[7];	// declaration or expression?
				// declaration!
		
		T (*p)[7]->m = 7;	// declaration or expression?
					// expression!

	}

The rule is that anything that (syntactically) looks like a declaration
is a declaration (this ensures C compatibility). What isn't might be an
expression.

This rule is simple, but requires a backtracking parser to cope with
``cute'' examples like the ones above.

Had I had 20/20 foresight I would probably have chosen an LALR(1) grammar
for C++. However, I did not (and still don't) consider syntax issues to be
anywhere near as important as issues of type checking and access control
so I underestimated people's desire/need for syntax based solutions.