SLUG Mailing List Archives
Re: [SLUG] yacc anybody?
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] yacc anybody?
- From: James <jam@xxxxxxxxx>
- Date: Sun, 27 Feb 2011 10:03:08 +0800
- User-agent: KMail/1.13.5 (Linux/2.6.35-24-generic; KDE/4.5.1; x86_64; ; )
On Sunday 27 February 2011 09:00:03 slug-request@xxxxxxxxxxx wrote:
> > Sections :
> > | Section Sections
> > | Lines
> The problem is two-fold. First, it is the convention to write iteration
> left recursively, as in
> : /* empty */
> | Sections Section
> This results in less depth in the parse stack, and in some cases (where
> rules are attached) results in a more-expected side-effect order (L2R
> rather than R2L).
> The second problem is that both Lines and Sections can be empty.
> This make the initial parse state ambiguous. Should it immediately
> reduce by the "Sections: /* empty */" rule, or by the "Lines: /* empty
> */" rule?
> Try this instead
> : Lines
> | Sections section
> Now there is no empty Sections rule, and all ambiguity goes away... the
> file always starts with a (possibly empty) non-section set of lines.
> When it doubt, always read the y.output file, it will document how and
> where ambiguities occur in your grammar.
Peter thank you. In a moment you have solved many days of muddling.
I *do* read y.output but I'm not clever enough to turn the reported conflict
into a solution <blush>