On Thu, 22 Jun 2006, Paul Eggert wrote: > "Joel E. Denny" <[EMAIL PROTECTED]> writes: > > >> Does order matter elsewhere? > > > > A few places at least. %union for dividing the pre-prologue blocks from > > the post-prologue blocks. > > Computing the start symbol (assuming no %start). > > Reduce-reduce conflict resolution. > > I suspect these are inevitable due to backward compatibility concerns > with Yacc.
Oh sure, but it's nice when Bison can offer cleaner alternatives. For example, %start. This discussion has emboldened me to propose a full alternative to prologue blocks (and I may be stealing it from a post from Akim, but I'm not sure). I don't think the user should have to use %union to organize prologue blocks. That interface is subtle and restrictive. For example, as I've mentioned before, the user may not want a %union. I addressed this by making %after-definitions and %before-definitions also divide the pre-prologue blocks from the post-prologue blocks. In doing so, I introduced more subtle order-dependent rules to keep up with. A few days ago, I was working on generating a grammar file. For reasons that are difficult to explain, it was most convenient to generate a %union declaration at the very top of the file. This meant that all my prologue blocks were post-prologue blocks. Yes, I found a work-around, but I think it would have been easier if I could have just *declared* that certain prologue blocks were pre-prologue blocks. In general, order-dependent declarations are subtle and restrictive. The user should be able to organize his grammar file as he sees fit. As I've mentioned before, I think the terms pre-prologue and post-prologue aren't quite right. What if we offer %before-header and %after-header as order-independent alternatives? That is, they would be blocks of code inserted into the code file before and after the contents of the header file. In that case, we could go back to having only %union separate the Yacc-style pre-prologue blocks from post-prologue blocks. That is, I would remove the influence of %before-definitions and %after-definitions on the old prologues. Less order-dependent rules to remember. Just to make sure I'm being clear: before the first %union, a prologue block would have the same function as %before-header does anywhere. After that %union, a prologue block would have the same function as %after-header does anywhere. What do you think? > > Precedence declarations. > > I'm not aware of this one. Does Yacc allow this? If so, I guess we're > stuck with allowing this as well. I just meant that the Yacc way of declaring static (token) precedence is by the order of the precedence declarations. %dprec uses numbers instead. I believe Akim has talked about partial/modular precedence declarations that may provide a cleaner alternative. He's also talked about the reduce-reduce conflict resolution issue. > > One %define can override an earlier %define. > > Yacc doesn't have %define. Can we change this to generate a > diagnostic instead of silently ignoring the earlier definition? Or is > there some use for overriding? I'm not sure. I don't know the history here. Maybe Akim knows? > Thanks for summarizing the situation. It's very possible I've missed some things. Joel
