On Fri, 11 Nov 2011 12:54:28 PST Bakul Shah <ba...@bitblocks.com> wrote: > On Fri, 11 Nov 2011 08:07:21 PST ron minnich <rminn...@gmail.com> wrote: > > If somebody wants to look at enhancing yacc so that the extra bison > > bits can be supported, that would probably do the trick. I have no > > idea of the level of effort, I have not looked. > > After some googling I see that src/cmd/gc/bisonerrors was > added by Russ in an evening to improve go error messages. > > Clinton Jeffery in his "Generating LR syntax error messages > from examples" paper (http://www.cs.nmsu.edu/~jeffery/merr.pdf > -- not sure if this is the same paper as the one in TOPLAS) > says his Merr program works with Berkeley yacc, AT&T yacc & > bison. He also refers to a modified byacc called iyacc. > > Might it be worth looking Merr or iyacc? Porting bison to > plan9 seems like a hugh punishment for a quick hack:-) > Implementing Jeffery's directly in yacc might benefit other > parsers as well.
Reading Merr code was useful but it is written in Icon so.... After staring at go.y, bisonerrors, go.errors, bison's y.output, and generated yerr.h for a while I think I understand what is going on. I believe everything needed is already in plan9's y.output -- no need to change yacc. It may be easier to just make bisonerrors handle this than convert plan9's y.output to bison compatible y.output. Of course, things may look much bleaker in the morning but this is what I think now! Given that an array of <state, terminal, message> is generated from y.output & go.errors, it is may be worth integrating this logic in yacc. But that is for another day. Ideally something like go.errors is interactively generated from actual errors (sort of like how a spellchecker works -- you are presented with an error + its context and you indicate the error message &/or fix). This is then fed back to yacc along with the grammar.
