4 Nov 2005 13:58:23 -0500

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

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.