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!