|additional regular expression operators email@example.com (Ralph Boland) (2009-03-29)|
|Re: additional regular expression operators firstname.lastname@example.org (2009-03-30)|
|Re: additional regular expression operators email@example.com (2009-03-30)|
|Re: additional regular expression operators firstname.lastname@example.org (Hans Aberg) (2009-03-30)|
|Re: additional regular expression operators email@example.com (2009-03-31)|
|Re: additional regular expression operators firstname.lastname@example.org (Ralph Boland) (2009-03-31)|
|Re: additional regular expression operators email@example.com (2009-04-14)|
|Re: additional regular expression operators firstname.lastname@example.org (MZL) (2009-04-15)|
|[4 later articles]|
|Date:||Mon, 30 Mar 2009 06:40:45 -0700 (PDT)|
|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
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. :-)
Return to the
Search the comp.compilers archives again.