Related articles |
---|
What is correct way to describe this in BNF for an LL(1) parser donmackay@optushome.com.au (don) (2005-11-02) |
Re: What is correct way to describe this in BNF for an LL(1) parser mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2005-11-04) |
What is correct way to describe this in BNF for an LL(1) parser rici@ricilake.net (Rici Lake) (2005-11-04) |
Re: What is correct way to describe this in BNF for an LL(1) parser donmackay@optushome.com.au (don) (2005-11-08) |
Re: What is correct way to describe this in BNF for an LL(1) parser henry@spsystems.net (2005-11-12) |
From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
Newsgroups: | comp.compilers |
Date: | 4 Nov 2005 13:58:23 -0500 |
Organization: | cbb software GmbH |
References: | 05-11-032 |
Keywords: | parse |
Posted-Date: | 04 Nov 2005 13:58:23 EST |
On 2 Nov 2005 22:13:51 -0500, don wrote:
> I can do everything I've needed to so far except for the absolute value
> function (eg | expression |). The problem is that the expression can
> expand back to this definition and, as it is simply stated now, the
> parser does not appear to tell the difference between closing '|' and
> the start of a nested expression. If I change the trailing "|" to
> something like '@' then the whole thing works OK.
That should not be the reason, as long as no expression can be empty or
contain | as an operand or operator (unary, dyadic, postfix).
> BTW, I also have the more standard " ABS ( expression ) " version and
> that gets me by for now, but I really would like the |...| notation as
> well.
I written several parsers with |x| for abs and so far experienced no any
problems. I'm using a different technique, though.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.