🚀 go-pugleaf

In article <4io1jt$nph@solutions.solon.com>,
Colin Fry <colin@tacos.caltech.edu> wrote:
>  If anyone has implemented a recursive decent C (or subset of C) parser,
>and would supply same please contact colin@tacos.caltech.edu. I have a YACC
>implementation of an interpreted C subset, but the users don't like the
>uninformative error messages. 

If that is your only problem, why not fix it with error productions? Yacc
parsers can be made quite friendly in reporting error messages. Don't give up
right away---someone else's recursive descent parser might be harder to
incorporate into your project, and more difficult to subsquently maintain, than
augmenting your existing one with more meaningful error productions.

You might also want to investigate the facilities of the GNU Bison parser
generator.



An error production is one which contains the special yacc keyword ``error''.

for example,

foo_declaration
	: T_VAR T_INTEGER ':' varlist '.'
	| T_VAR T_REAL ':' varlist '.'
	| T_VAR T_INTEGER error '.'
	{
		errorprint("colon expected after `integer'");
	}
	| T_VAR error '.'
	{
		errorprint("unknown variable type!\n");
	}
	;

This first error production means that if an error is encountered in parsing the
foo_declaration after the parser has seen the T_INTEGER keyword, it will detect
a syntax error, then keep reading input symbols until it sees a terminating '.'
after which it will reduce by the error production and do the action.

The second error production will kick in of the T_VAR keyword symbol is
immediately followed by a parse error, which means that it was not followed by
T_INTEGER or T_REAL.

[warning: yacc is not C, and further discussion of Yacc should probably
 go to another newsgroup. -mod]
--