[Top][All Lists]
[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