--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> > paragraph ::= PARA text.
>
> I observed the new PARA terminal token (the clear separator!?). Unfortunately
> the lexer does not
> generate such a token. Paragraph repeats are also removed.
It was just an HTML-like example. I just wanted to demonstrate one
possible way to remove the conflicts by adding a special tag.
I'm not suggesting that you alter your grammar in this way.
> >Here's another:
> >
> > article ::= blocks.
> >
> > blocks ::= block.
> > blocks ::= blocks block.
> >
> > block ::= heading NEWLINE.
> > block ::= paragraph NEWLINE.
> >
> > heading ::= HEADING_START text HEADING_END.
> > heading ::= HEADING_START text.
> > heading ::= HEADING_START.
> >
> > paragraph ::= text.
> >
> > text ::= textpiece.
> > text ::= text textpiece.
> >
> > textpiece ::= TEXT.
> > textpiece ::= LINK.
>
> This one also removes paragraph repeats, doesn't it? Unfortunately paragraphs
> need to repeat for
> my grammar. Is there a way to achieve this without conflicts?
In your original grammar, you could have random sequences of TEXT
and LINK and NEWLINE tokens without any way of differentiating whether
they were part of a "text" or "paragraph" or "heading", hence the conflict.
So I figured that a paragraph may as well be any combination of
TEXT and LINK tokens ending with NEWLINE. The headings in my 2nd grammar
also have to end with NEWLINE. "paragraph" will not repeat, per se, but you
can repeat "block" (see the "blocks" rules), where you can have several
consecutive "block"s that happen to be of type paragraph so you can achieve
the same effect.
The following grammar may be clearer to you:
article ::= blocks.
blocks ::= block.
blocks ::= blocks block.
block ::= heading.
block ::= paragraph.
heading ::= HEADING_START text HEADING_END.
heading ::= HEADING_START text NEWLINE.
heading ::= HEADING_START NEWLINE.
paragraph ::= NEWLINE.
paragraph ::= text NEWLINE.
text ::= textpiece.
text ::= text textpiece.
textpiece ::= TEXT.
textpiece ::= LINK.
It's much the same as the previous grammar, but puts the NEWLINEs as part
of the paragraph and heading rules instead of in the block rule.
The difference being that heading no longer needs to end with NEWLINE
in one case if HEADING_END is encountered, as it is not ambiguous:
heading ::= HEADING_START text HEADING_END.
and a paragraph in this grammar may also be empty so you can parse
consecutive NEWLINE tokens with this rule:
paragraph ::= NEWLINE.
Again, this was just an example of how to disambiguate the grammar.
You can find other ways.
> >Lemon generates an .out file for the .y file processed.
> >You can examine it for errors.
>
> I have tried to make sense of the .out file before. It tells me where to look
> for the problem,
> but not how to fix it ...
Try reading some papers on parsing or search for the book
"Compilers: Principles, Techniques, and Tools" (a.k.a.
the dragon book).
Also try writing on paper random sequences of tokens and
manually parse your grammar to see the conflicts firsthand.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
