help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposals for various changes to the Java parser


From: Paolo Bonzini
Subject: Re: Proposals for various changes to the Java parser
Date: Wed, 29 Oct 2008 20:06:16 +0100
User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914)

> I'm only talking interface, not implementation.  I don't want a class
> that includes all union members as fields.  Rather, the m4 code would
> lookup the ``field'' name in %union and generate the cast like the
> existing code.

Oh, I see.  Actually the first implementation was done that way, strange
I didn't understand what you meant!  I changed it because parsing the
%union in m4, basically by matching

   ([^;]*[^; \t])[ \t]*\<FIELD\>[ \t]*;

was a bit brittle.

> # b4_rhs_value(RULE-LENGTH, NUM, [TYPE])
> # --------------------------------------
> # Expansion of $<TYPE>NUM, where the current rule has RULE-LENGTH
> # symbols on RHS.
> #
> # In this simple implementation, %token and %type have class names
> # between the angle brackets.
> m4_define([b4_rhs_value], [(m4_ifval($3, [($3)])[](yystack.valueAt
> ($1-($2))))])
> 
> Then $<Map/*String,String*/>1 would mess up the arguments of m4_ifval:
> the test would be ``Map/*String'' and the if-true part would be
> ``String*/''.  The fix is just to put an m4_quote around the test.

I will check it out.

> Should we make errorVerbose final to match C?

No, as you said it's nice to be able to change it.

> As for whether to include the code without %verbose-error, 
> for people looking at the code generated by their parser specs, it's
> probably better not to have code that's never used.

Yes, we agree on that.

> 20. Put EOF and other token type names in the Lexer interface instead.
> These names are supposed to be returned from the Lexer, so why require
> extra qualification (when not using ``%code lexer {...}'')? Also, there
> is no use for these names in the parser except to pass to yy_translate_
> to get the internal symbol number and get some info on the grammar.  And
> YYBACKUP and yychar is not currently supported by Java.
> In any case, use within the lexer would be much more common than in the
> parser.

Okay.

> 21. Add ``$code init {...}'' for code added to the start of the
> generated parser constructor.  This is particularly important with
> ``%define extends'' to allow the superclass to be initialized.  Also add
> ``%define init_throws''.

Okay.

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]