[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISO C grammar / hanging else / dual transformation
Hi Roger, all,
> One last query: In the following grammar I am doing a dual
>
>
About the last query, you are absolutely right :
++ SableCC error messages need to be more explicit. I'm working on it.
++ For the assignment_expression transformations, you are also right.
In fact, i've discovered that the bug is related to non authorized
multiple invocation of assignment_expression.expression
(more generally some_element.transformation) which is not checked in SableCC.
This has to be fix and i think i should be able to do that this weekend.
I'm sorry but i have no time right now to work on it.
thanks for the report.
Cheers,
kevin
On Mon, 26 May 2003, Roger Keays wrote:
> Hi All,
>
> Attached is a grammar based on the ISO C standard. An AST version will
> follow in a few months when it has stabilized.
>
> There are a couple of bugs in this grammar that I could use a hand
> with. The first is the classic hanging else problem (line 649):
>
> /* 6.8.4 selection-statment */
> selection_statement =
> {if} kw_if tok_lpar expression tok_rpar statement |
> {ifelse} kw_if tok_lpar expression tok_rpar statement kw_else
> [other]:statement |
>
> Is there a simple way to solve this in SableCC? My temporary solution
> is to require compound_statements for an ifelse production.
>
> The second is a shift/reduce conflict that means I have had to remove
> the typedef_name (line 470) production. The problem is, the parser
> cannot distinguish between a typedef_name production (just an
> identifier) and a direct_declarator.identifier production (also just an
> identifier).
>
> One last query: In the following grammar I am doing a dual
> transformation which seems to work fine.... except... I get the error
> that the last 'expression' must appear on the left hand side of the
> arrow. It IS on the left hand side of the arrow, but is referred to
> twice on the right hand side. The 'assignment_expression' is also in
> the same boat, however there is no error for it.
>
> expression -> [long_list]:expression+ [single_list]:expression =
> {no} assignment_expression
> -> (assignment_expression.expression)
> New expression.list((assignment_expression.expression))
> |
> {list} expression tok_comma assignment_expression
> -> (expression.long_list assignment_expression.expression)
> New expression.list
> ((assignment_expression.expression
> expression.long_list));
> ^^^^^^^^^^
> I have spent some time examining the source to discover why this is the
> case, but it is very difficult to follow due to the lack of comments!
> (I'll never stop complaining about this :) ... comments are more useful
> than actual source!)
>
> Thanks all, it's great to see SableCC development so active!
>
> Roger Keays
> ------------------------------------------------------------------------
> ninthave.net p: +61 7 3870 8494
> Web Hosting m: +61 405 048 371
> Web Design w: http://www.ninthave.net
> Programming e: r.keays@ninthave.net
> ------------------------------------------------------------------------
> http://groups.ninthave.net Complete hosting solution for communities
> http://billshare.ninthave.net The easy way to manage your bills!
> http://pic.ninthave.net THE C compiler for PIC micros
> ------------------------------------------------------------------------
> http://clubs.sport.uq.edu.au/uqtrifit UQ Triathlon Club
> http://groups.msn.com/SunshineCoastCycling Sunshine Coast Cycling Club
> http://groups.ninthave.net/dance UQ Dance Club
> http://www.cashflowclub.org.au UQ Cashflow Club
> http://groups.msn.com/uQRomanceLanguagesClub UQ Romance Languages Club
> ------------------------------------------------------------------------
>