Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!houxz!vax135!floyd!harpo!decvax!cca!ima!ism780!abe From: abe@ism780.UUCP Newsgroups: net.unix-wizards Subject: Re: anyone played with yacc? - (nf) Message-ID: <236@ism780.UUCP> Date: Wed, 13-Jun-84 00:24:35 EDT Article-I.D.: ism780.236 Posted: Wed Jun 13 00:24:35 1984 Date-Received: Thu, 14-Jun-84 00:43:19 EDT Lines: 38 #R:clyde:-45000:ism780:14400010:000:1031 ism780!abe Jun 11 11:00:00 1984 In addition to having a very large yacc executable, this approach has the drawback of not being able to compile your system on anything but your own local hacked-yacc. Another approach, if you are somewhere near the 127-terminal limit, is to have various local rules do their own keyword-parsing. E.g. if you had something like: type_specifier: INT | LONG | CHAR | SHORT . . . and the INT, LONG, etc. are not used elsewhere as terminals, you can remove the definitions of these as tokens, and do something like: type_specifier: identifier { if (equal(yytext, "int")) ... else if (equal(yytext, "long")) ... else (printf("illegal type specifier\n")); } Of course, you have to be careful that this doesn't introduce ambiguities into the grammar. The above example is probably bad since it deals with a pretty significant part of the language; but innocuous areas where the above procedure can be used are probably present, especially if you've gone over the 127-token limit!