[9fans] all you yacc experts

[bakul@bitblocks.com (Bakul Shah)]

On Fri, 11 Nov 2011 12:54:28 PST Bakul Shah <bakul at bitblocks.com>  wrote:
> On Fri, 11 Nov 2011 08:07:21 PST ron minnich <rminnich at 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.