Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!milano!cadillac!pebbles!ned
From: ned@pebbles.cad.mcc.com (Ned Nowotny)
Newsgroups: comp.lang.c++
Subject: Re: zortech problem with lex
Message-ID: <6553@cadillac.CAD.MCC.COM>
Date: 4 Mar 90 19:22:30 GMT
References: <6300008@ux1.cso.uiuc.edu> <24800002@sunb6> <25ECE752.29589@paris.ics.uci.edu> <10541@alice.UUCP>
Sender: news@cadillac.CAD.MCC.COM
Reply-To: ned@MCC.COM (Ned Nowotny)
Organization: MCC CAD Program, Austin, TX
Lines: 40

In article <10541@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
>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.

Given the imprecise nature of the C++ specification, I am more than a
little disappointed that the language does not have a grammar expressible
in BNF form that will accept all legal strings and reject all illegal
strings.  (That, by the way, is what I consider to be the test of whether
a given language is specifiable by a given grammar.  While it may be
true that some LALR(1) grammar will accept all legal C++ strings, the fact
that the grammar must also accept illegal strings makes the claim that
C++ is somehow a LALR(1) language something less than useful.)  For example,
when trying to resolve whether bugs in my code are the result of an incorrect
understanding of the language on my part or a flaw in a given compiler, I would
like to turn to an authoritative source to determine whether a given string
I have written is even a legal construct.  Unfortunately, the grammar given
in the various reference manuals are not helpful precisely because they are
not accompanied by a formal specification of the "smarts" built into the
lexical analyzer.  In fact, the specifications would not be as precise as
a LALR(1) grammar in any case.  The current (and, quite probably, permanent)
situation is of little assistance to compiler writers and users of C++ alike.

(For example, consider const friend functions:  Everything I have read,
including Lippman and the Release 2.0 Reference manual, SEEM to indicate
that only member functions may be declared const functions.  However,
Keith Gorlen, for one, has declared friend functions to be const in his
NIH Class Library code.  This appears to be a reasonable thing to do.  The
grammar given in the 2.0 reference manual does not appear to disallow this,
there is no semantic specification provided which disallows it, the Cfront
2.0 compiler which is the current reference implementation apparently
accepts it, and it appears on its face to be a reasonable thing to do.  A
precise LALR(1) grammar would, at least, disambiguate the current legality
of the construct while greater minds considered its usefulness and hazards.)

Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX  78720  Ph: (512) 338-3715
ARPA: ned@mcc.com                   UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.