Re: Strange behavior

[Laurent Deniau]

Hans Aberg wrote:
> At 09:34 +0200 2004/03/29, Laurent Deniau wrote:
>
> > Nothing about my question?
>
>
> I think your question was answered by Tim Van Holder: Due to limitation in
> lookahead in the LALR(1) parser generator algorithm, one has to fiddle
> around with the grammar to find a form that works.

Well, I was maybe not very clear in my question but basically I was 
asking why two equivalent rules are not considered as equivalent by 
bison. In both cases, no more lookahead is needed, but it is true that 
more states are created in the second case. But from my point of view it 
is a completely different point. By the way, this happened only for one 
optional rule over more than 20 used and if I try to reproduce it for a 
smaller grammar, the problem vanishes. And looking at the verbose output 
shows clearly that the conflits are not justified, and the behavior is 
correct since the optional rules are standing alone. Otherwise I would 
have post my question to help-bison, not bug-bison.

> > > This is not really a Bison question, but a question of implementing a
> > > language using the LALR(1) parsing algorithm. As your language is
> > > well-known, it might be worthwhile asking around in the newsgroup
> > > comp.compilers, or in some of the C newsgroups to see if somebody already
> > > has done it. Some C compilers might already have it (GNU C?).
> >
> > My question has nothing to do with the C99 grammar. It was just to fix
> > the background, nothing more.
>
>
> So therefore, if the implemented language is known, it can be worth to look
> around for tricks that may be required to implement it.

I do not understand your point. What do you mean by the language is 
known? The norm of the C99 provides a "descriptive" grammar of the 
language but it is neither normative (only informative) neither it 
works. You have to modify it deeply to make it working with a LALR(1) 
parser because it has contexts. But again, this has nothing to do with 
my question. My question is about bison.

> > > Tip: It is might be better to avoid the single quote ')' constructs, and
> > > instead use
> > > %token LP "("
> > > %token RP ")"
> > > ...
> > > %%
> > > ...>direct_abstract_declarator
> > >   : "(" abstract_declarator ")"
>
> ...
>
> > > Then your Flex grammar must have lines
> > > "("   { return RP; }
> > > etc.
>
> ...
>
> > Using string here is quite dangerous since you replace the character
> > ASCII value by a string literal address. No a good idea...
>
>
> In the handshake with the lexer, one is instead using usual token numbers
> instead of character code numbers, which should in principle enable a
> smaller parser token table.

Right, but the parser is small enough to favour the readibility instead 
of the compacity.

> The strings are only exported to the parser to
> a table used for error message printouts, which has strings in it anyway.

But you still need to write the rule with LP and RP.

direct_abstract_declarator
        : LP abstract_declarator RP

Thanks for your answer.

Cordialement,

ld.