|What is correct way to describe this in BNF for an LL(1) parser email@example.com (don) (2005-11-02)|
|Re: What is correct way to describe this in BNF for an LL(1) parser firstname.lastname@example.org (Dmitry A. Kazakov) (2005-11-04)|
|What is correct way to describe this in BNF for an LL(1) parser email@example.com (Rici Lake) (2005-11-04)|
|Re: What is correct way to describe this in BNF for an LL(1) parser firstname.lastname@example.org (don) (2005-11-08)|
|Re: What is correct way to describe this in BNF for an LL(1) parser email@example.com (2005-11-12)|
|From:||firstname.lastname@example.org (Henry Spencer)|
|Date:||12 Nov 2005 16:40:12 -0500|
|Organization:||SP Systems, Toronto, Canada|
Rici Lake <email@example.com> wrote:
>mult-expr ::= pow-expr '/' mult-expr
> | pow-expr '*' mult-expr
> | pow-expr mult-expr ;; implicit multiplication
>term ::= '|' expr '|'
> | '(' expr ')'
> | VAR
> | NUMBER
>(I don't know what tool you are using or any details of your grammar;
>this is just a guess. Make appropriate substitutions, or ignore me if
>I'm guessing wrong.)
>If it were not for implicit multiplication, the use of |x| for abs(x)
>is unambiguous (providing you're not using | for other things as well...
It can be unambiguous even with implicit multiplication, at the cost of
a bit more grammar complexity. Consider (using RFC 2234 ABNF):
expr = term
/ expr term ; implicit multiplication
term = "|" aexpr "|"
aexpr = aterm
/ aexpr aterm
aterm = "(" expr ")"
This excludes nested absolute-value operators unless the inner ones are
enclosed in parentheses. With a full set of operators it would get
tedious, since it essentially duplicates the expression syntax with one
form excluded, but it *does* work.
spsystems.net is temporarily off the air; | Henry Spencer
mail to henry at zoo.utoronto.ca instead. | firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.