Re: Grammar ambiguity

Jocelyn Coulmance <j.coulmance@itecor.com> schrieb in im Newsbeitrag:
> Maybe you should try to write a LALR(k) grammar rather than a LALR(1)
> one. LALR(k) grammars allow much more natural constructs. In this
> case VisualParse is a nice tool than can save you a lot of time.


Thanks for the pointer.


> As for the semicolon issue, - if you are talking about Eiffel,


Yes. (How did you know? <g>)


> you can insert an optional semicolon in the grammar and resolve the
> conflict in favour of a shift. The parser will accept some illegal
> inputs but later stages will correctly discard them.


I'm *very* suspicious of such changes. You have to fully understand
all the consequences to be 100% sure that the change affects just the
grammar and doesn't inadvertently change the recognized language as
well.


> - if you are talking about a new language, get rid of this rule ;) A
> way to do so is to treat semicolons and line terminations as
> equivalent and force one of them in certain places:
>
> p1
> (a+b).p2 -- 2 different instructions since there is a line
> termination in between
>
> p1; (a+b).p2 -- idem since there is a semicolon
>
> p1(a+b).p2 -- only one instruction


Hmm... yes, I've been thinking along these lines. Unfortunately, this
prevents me from having multi-line expressions. I've tried to work
around this, but the results were not encouraging.


Regards,
Joachim

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