Re: What is correct way to describe this in BNF for an LL(1) parser

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
4 Nov 2005 13:58:23 -0500

          From comp.compilers

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)
| List of all articles for this month |

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



Post a followup to this message

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