Hi, I didn't managed to find the corresponding discussion in the mailing list, but as far I remember, it is impossible to obtain an unambiguous grammar with syntax extensions like id '[' c_id ']' without involving the ';' requirement. It is also not desirable to change the type of the grammar or to maintain two separate grammars.
I totally agree with the general statement, but just not seeing any reasonable solution. Please suggest one. Alex On Tue, Jan 18, 2011 at 9:11 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > On 01/15/11 22:28, Alex Rozenman wrote: > > Currently I am very busy with other tasks. Please allow me couple of days > to review it. > > One other thought, while we're on the subject. Currently we are handling > bracketed constructs, such a [x], [y], and [z] in this rule: > > foo[x]: foo[y] '+' foo[z]; > > in a combination of C and lex. That is, the "[x]" is a single token > in the grammar for Bison grammars, and there's a long bit of C+lex code to > allow things like "[x /*hello*/]" while disallowing things like "[x > /*hello*/y]". > This is not good. We have a nice compiler-compiler, and we're not using > it, > but instead we have a sortof-parser in C and lex. > > We should parse these bracketed constructs with a Bison grammar, so that > "[", "x", and "]" are all single tokens, and so that the grammar tells us > which things are allowed in brackets. > > I suspect that the reason it's done the way it is, is because of the old > backward-compatibility concern with rules that do not end in ';'. But > there's no reason to cater to these backward-compatibility concerns with > this new construct. No grammars should use this new construct, without > also putting ';' at the end of every rule. > -- Best regards, Alex Rozenman (rozen...@gmail.com).