From 40165023577946910 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,a96d3826c7356af2 X-Google-Attributes: gidf78e5,public From: Steve Clamage Subject: Re: Semantic-context keywords (was Re: Global "if" statement?) Date: 1997/05/10 Message-ID: <33723CC9.5532@Eng.Sun.COM>#1/1 X-Deja-AN: 240448467 References: <3366E8FF.3E38@ix.netcom.com> <5kfha7$1s9@mulga.cs.mu.OZ.AU> <5kl75e$mbn@fs7.ece.cmu.edu> <336F6D40.74E6@Eng.Sun.COM> <5kqfei$49j@fs7.ece.cmu.edu> X-Original-Date: Thu, 08 May 1997 13:51:21 -0700 Organization: Sun Microsystems, Inc. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM3QGwuEDnX0m9pzZAQFpBQF9Fwx7+te/fZC12lThc9kPbWY/pfiw5sEd DAu9kZ0VtiAcHXBYontEnsQp4b708H5s =J0u4 Newsgroups: comp.std.c++ Originator: fjh@mundook.cs.mu.OZ.AU David A. Cuthbert wrote: > > Steve Clamage replied: > >As best I remember, no one ever seriously considered keywords that > >weren't always reserved. Parsing C++ is already difficult, and adding > >unnecessary complications isn't going to win any votes. Error reporting > >is also better when the program context does not affect which words > >are keywords. > > I think that the quality of implementation affects error reporting > more than the parsing method. One of my peeves are the messages > ") expected", ", expected", and "; expected". I usually want to ask > the compiler, "Why? Tell me what you thought I was trying to do > (function decl, etc.), so that I can disambiguate and tell you what I > really want to do." That is probably so, but is a different point. Independent of parsing method and the implementor, some language design choices can make error reporting easier or more difficult. Assumptions: Quitting after finding one syntax error is not acceptable. The compiler should recover (resynchronize) after finding an error and continue analysis to find as many of the actual errors as possible in any one run. Reporting "errors" that are artifacts of losing synchronization is not desirable, and should be kept to a minimum. Example: Why require semicolons to terminate expression statements? x = y a = b is clear enough. The "a" following the "y" cannot possibly be part of the same expression or statement, so it must begin a new statement. You don't need a semicolon separator. Answer: Apart from possibly reducing ambiguities, the semicolon represents a "reliable token" that positively indicates the end of an expression, and also the end of most statements. (A for-header is an exception.) That is, when you encounter a semicolon token, you can reset the expression parser unconditionally. Without a required semicolon, many kinds of typographical or other errors in the source code make it hard or impossible to determine where you can can continue parsing and looking for more errors. If you try to resynchronize too soon, you generate a lot of bogus error messages due to misinterpreting what might be valid code. You have to skip ahead to some other "reliable token" like a closing brace. On the other hand, since a semicolon IS required to terminate an expression statement, the compiler can report a missing semicolon after the "y", pretend it saw one, and continue parsing accurately. Notice this is a language design issue independent of any particular grammer or parsing method. Similarly, if context determines whether an identifier is a keyword, it is that much harder for the parser to resynchronize after finding a syntax error. In the presence of syntax errors, you can't be sure you are making the right assumptions about context, and thus can't be sure whether you are looking at an ordinary identifier or a keyword. That in turn makes further recovery more difficult. > Anyway, I mentioned this because I've noticed that most extensions > that to C that make up C++ try to use existing syntax in odd, > counter-intuitive ways as much as possible. This avoids adding > keywords and utilizes expressions that were illegal (good for > backwards compatability). You have to wonder, though, if these same > guidelines should apply to fresh code that uses no legacy features > (i.e.: shouldn't such code be written in C++++?). I don't think this observation is correct. Most added features of C++ are not backwards compatible with C, and no attempt was made to make them backwards compatible. C compilers cannot deal with general C++ class declarations, scope modifiers, pointers to members, new/delete, overloaded operator functions, namespaces, exceptions, or templates, for example. -- Steve Clamage, stephen.clamage@eng.sun.com --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]