help-bison
[Top][All Lists]
Advanced

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

Re: How to read and understand the bison report file ?


From: Akim Demaille
Subject: Re: How to read and understand the bison report file ?
Date: Thu, 28 Jun 2012 16:57:48 +0200

Le 28 juin 2012 à 16:47, Timothy Madden a écrit :

> I would try to include my spaces in the lexer tokens, and I have updated the 
> lexer input for that, but I have some things I should understand first, like 
> how does that help the grammar ?

Well, are you familiar with LR parsers?  You should, if you
want to understand this.  But basically the idea is that
since it won't see the ws+c, then it will be able to see
what is immediately behind a given symbol, whereas before,
it could be arbitrarily far away, separated by an unbounded
amount of spaces.

> My token type is always std::string, no need for that union. I am eager to 
> see the new variant-based token type you guys are working on, I think that 
> will really make the C interface "obsolete". :) Can you also include some 
> common members, not only alternative members, in the variant ?

Nope.

> Sometimes I want to have a member that selects the token type, and then a 
> union where I select a member from, basted on the previous token type, like
> 
> struct token
> {
>    enum TokenType { int, string }
>       token_type;
> 
>    variant
>    {
>        int intToken;
>        str strToken;
>    }
> };
> 
> Back to my grammer file, I think I should still read some more documentation 
> pages about precedence, as I kinda hoped to avoid that with more grammar 
> rules, that would make precedence unnecessary for expressions.
> 
> Sorry to say the bison documentation is kind of unpleasant to read.

Well, precise suggestions are most welcome.  Yet I am surprised: I
find it quite nicely written.

> A significant number of the initial chapters never attempt to cover one 
> single item or aspect of bison completely.

The beginning is an introduction.  Then come the reference material.

> So I am never confident on what little I have already learned from those 
> chapters, until I get to the reference chapters.
> 
> But if a rule like
> 
> if (expr)
>    stmt;
> [elseif (expr)
>    stmt; ]
> [elseif (expr)
>    stmt; ]
> [else
>    stmt; ]
> 
> can be made legal LALR(1), than I no longer understand what is wrong with the 
> explicit spaces all over every one of my grammer rules.

Reread what I explained.

> With my entire grammar, attached previously, ignoring those hundreds of 
> conflicts I get 'syntax error' on the first binary operator in my php input 
> file ("=". "+", "*", T_INSTANCEOF, ...). The rules for those operators seem 
> pretty clear to me in the grammar. Trying to get that diagram with the `dot` 
> tool from graphwiz took over 48h without completion on an Inter Core 2 Duo, 
> after which I stopped the process.

Graphical rendering is absolutely useless with large grammars.
In fact, it's only usable for toy grammars.  This is made for
beginners willing to "see" the automaton.  The *.output is the
really useful part.




reply via email to

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