Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: zortech problem with lex Message-ID: Date: 28 Mar 90 15:59:00 GMT References: <6300008@ux1.cso.uiuc.edu> <24800002@sunb6> <25ECE752.29589@paris.ics.uci.edu> <10541@alice.UUCP> <6553@cadillac.CAD.MCC.COM> <25F8C92A.9349@paris.ics.uci.edu> <3742@tukki.jyu.fi> <26073795.10139@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: I fully admit that C and C++ are easier to "compile" if you have separate token types for "identifier" and for "type name", but is this absolutely manditory? I think not. Without having such distinctions made at the lexical level (or the basis of feedback from semantic analysis), you will of course end up with excessively general non-terminals like (for instance): declarative_or_executable_statement: But this is the meat of _my_ argument: this is no longer a grammar for C++, it is a grammar for a family of languages of which C++ is a member, and you use semantic (context dependent) rules to translate/disambiguate it to a C++ grammar. This is a fine implementation technique; you parse a more general language, and rely on non-grammar rules to narrow it down. Whether the *language* admits a context free, LALR(1) grammar (it does not) is one issue, whether the *compiler* can make use of a LALR(1) parser generator plus semantic analysis (it can) is an issue of how to engineer a parser for a non context free language using a mixed bag of tools. Essentially, using a LALR(1) parser generator aided by semantic analysis is hand crafting an attribute grammar parser. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk