|[5 earlier articles]|
|Re: Grammar ambiguity firstname.lastname@example.org (Joachim Durchholz) (2000-02-12)|
|Re: grammar ambiguity email@example.com (Chris F Clark) (2000-02-12)|
|Re: Grammar ambiguity firstname.lastname@example.org (Charles E. Bortle, Jr.) (2000-02-13)|
|Re: Grammar ambiguity email@example.com (Jocelyn Coulmance) (2000-02-19)|
|Re: grammar ambiguity firstname.lastname@example.org (2000-02-21)|
|Re: grammar ambiguity email@example.com (Chris F Clark) (2000-02-27)|
|Re: Grammar ambiguity firstname.lastname@example.org (Joachim Durchholz) (2000-02-27)|
|Re: grammar ambiguity email@example.com (Joachim Durchholz) (2000-02-27)|
|Re: Grammar ambiguity firstname.lastname@example.org (Jocelyn Coulmance) (2000-03-03)|
|Grammar ambiguity email@example.com (Vassilis Kostakos) (2000-03-06)|
|Re: Grammar ambiguity firstname.lastname@example.org (2000-03-11)|
|Re: Grammar ambiguity email@example.com (Rodrigo Augusto Barbato Ferreira) (2000-03-11)|
|From:||"Joachim Durchholz" <firstname.lastname@example.org>|
|Date:||27 Feb 2000 02:49:21 -0500|
Jocelyn Coulmance <email@example.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
> - 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:
> (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.
Return to the
Search the comp.compilers archives again.