[Groff] Re: parsing a corner specification

[Joel E. Denny]

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.