Re: simple ambigous grammar...

rkrayhawk@aol.com (RKRayhawk)
27 Aug 2000 22:28:28 -0400

          From comp.compilers

Related articles
simple ambigous grammar... abate@zed.students.cs.unibo.it (2000-08-21)
Re: simple ambigous grammar... llkparsing@aol.com (2000-08-27)
Re: simple ambigous grammar... rkrayhawk@aol.com (2000-08-27)
Re: simple ambigous grammar... gvmt@bgl.vsnl.net.in (Venkatesha Murthy G.) (2000-08-27)
| List of all articles for this month |

From: rkrayhawk@aol.com (RKRayhawk)
Newsgroups: comp.compilers
Date: 27 Aug 2000 22:28:28 -0400
Organization: AOL http://www.aol.com
References: 00-08-109
Keywords: parse

pietro, abate@zed.students.cs.unibo.it ()
Date: 21 Aug 2000 00:06:07 -0400
Organization: Compilers Central


writes
<<
But since I've no delimiters between expression,
and yacc has only one lookahead, this does not work.
Which is the right grammar to parser my expression ?
>>


It is not necessary to have what we sense as delimiters (between
statements or anywhere else) in a grammar in order for a lookahead(1)
tool to work.


A tool, like yacc, is always trying to either shift the next lookahead
onto a stack or to reduce what is on the stack already. In a certain
sense, once the tool sees that that next token can not be shifted (is
not a continuation of an even longer recognized sequence) it must
reduce what it has so far or signal an error.


You do have a high level iterator


AL -> AL A | A


which should be able to swallow one assignment after another,
delivering in the end, a long assignment list.


Using the symbolism you published :


AL -> AL A | A
A -> ID = E
E -> E + T | T
T -> T . F | F
F -> ID


if maybe useful for you to re-enter the expression-term-factor
structure, recursively. Perhaps, simplistically;


E -> E + T | T
T -> T . F | F
F -> ID | E


It is not rare for designers to expect imbedded expressions to be sandwiched
between parentheses, as in


E -> E + T | T
T -> T . F | F
F -> ID | ( E )


Also it is not rare, to try to deal with unary plus/minus in that same rule (F
-> .....) but I digress.


The presence of E or (E) in the F-> rule will tell the tool to shift that much
more onto the stack.


As humorous as it seems, the open parenthesis is actually an
anti-delimitter (trying to stretch across the pond let me pen
'contra-delimitter' alternatively). It is a grammatical device that
says 'this is NOT the limit of the foregoing text, keep on gluing more
stuff onto the stack'.


In passing, I will encourage you to indicate the actual error you are
experiencing from your tool, and give us a hint as to whether you are
up to speed yet on associativity.


Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.