Please CC me on replies as I'm subscribed to digest. On Sat, 18 Aug 2007, Yu Zhao wrote:
> Look into src/preproc/pic/pic.y, that your first example goes to "label" > because of the lower precedence of "left", and causes an error. > > In the second one, "upper", which has higher precedence than "CHOP", works > well since it is "label corner" rather than "label". I do understand why the parser, as written, behaves as it does. However, the explanation above is not the whole story. When encountering the LEFT token here, it doesn't make sense that the parser choses reduce when that leads to a syntax error even though a shift would have allowed the parse to complete successfully. That is, it doesn't make sense when you consider the grammar and precedence declarations alone given that they do accept the example input sentence. It does make sense when you consider the parsing technique employed, LALR(1). The parser state here did not originally have a reduce on LEFT and thus it did not have a conflict on LEFT. It always chose shift on LEFT. However, because of LALR(1) merging, it has picked up the LEFT lookahead from another state. The merged state then has a conflict that's resolved as reduce. Thus, a canonical LR(1) parser would have been more true to the grammar because it would never have merged these states. In any case, my real question is not about why or how the parser has this behavior. The why or how is what motivated me to ask my real question: Is the behavior intended? What do the pic developers, user community, or specifications say *should* happen? Maybe the developers intended to employ this effect of LALR(1) to achieve the current behavior. Maybe this usage is just so obscure that no one has ever had motivation to explore the behavior. Thanks for your response. Hopefully this makes my question clearer.
