Re: additional regular expression operators

m.helvensteijn@gmail.com
Mon, 30 Mar 2009 06:40:45 -0700 (PDT)

          From comp.compilers

Related articles
additional regular expression operators rpboland@gmail.com (Ralph Boland) (2009-03-29)
Re: additional regular expression operators m.helvensteijn@gmail.com (2009-03-30)
Re: additional regular expression operators zaimoni@zaimoni.com (2009-03-30)
Re: additional regular expression operators haberg_20080406@math.su.se (Hans Aberg) (2009-03-30)
Re: additional regular expression operators torbenm@pc-003.diku.dk (2009-03-31)
Re: additional regular expression operators rpboland@gmail.com (Ralph Boland) (2009-03-31)
Re: additional regular expression operators torbenm@pc-003.diku.dk (2009-04-14)
Re: additional regular expression operators zayenz@gmail.com (MZL) (2009-04-15)
[4 later articles]
| List of all articles for this month |

From: m.helvensteijn@gmail.com
Newsgroups: comp.compilers
Date: Mon, 30 Mar 2009 06:40:45 -0700 (PDT)
Organization: Compilers Central
References: 09-03-111
Keywords: lex
Posted-Date: 30 Mar 2009 10:58:36 EDT

> I have three choices:
> a) Have all unary operators follow their expressions.
> b) Have all unary operators preceed their expressions.
> c) Leave the original unary operators alone but have the
> new unary operators precede their expressions.
> The original unary operators take precedence.
> d) Give the user the ability to choose which to use.


You are suggesting an extension of regular expressions. Since both the
POSIX standard and Perl use the postfix notation for the standard
unary operators, option b will just confuse users. Or worse, they will
use postfix notation accidentally and in some cases your parser will
silently accept it.


Option c will introduce extra ambiguity into your grammar, which
doesn't feel right. Your choice to give the new operators lower
precedence seems rather arbitrary. Presumably, there will be use cases
in which your new operators need to bind more strongly than the
existing ones. In any case, parentheses need to be used, which are not
pretty. Option d is just needlessly complicated. No one will ever be
able to read one of your expressions and know unequivocally what it
means.


That leaves option a. I don't see what's so bad about the postfix
notation anyway. You did admit postfix operators are not uncommon. And
if you're really worried about parsing speed, just parse the
expression right-to-left. :-)


--
Michiel Helvensteijn
m.helvensteijn@gmail.com



Post a followup to this message

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