|additional regular expression operators firstname.lastname@example.org (Ralph Boland) (2009-03-29)|
|Re: additional regular expression operators email@example.com (2009-03-30)|
|Re: additional regular expression operators firstname.lastname@example.org (2009-03-30)|
|Re: additional regular expression operators email@example.com (Hans Aberg) (2009-03-30)|
|Re: additional regular expression operators firstname.lastname@example.org (2009-03-31)|
|Re: additional regular expression operators email@example.com (Ralph Boland) (2009-03-31)|
|Re: additional regular expression operators firstname.lastname@example.org (2009-04-14)|
|[5 later articles]|
|From:||Ralph Boland <email@example.com>|
|Date:||Sun, 29 Mar 2009 23:49:30 -0700 (PDT)|
|Posted-Date:||30 Mar 2009 08:44:58 EDT|
I am building a tool for translating regular expressions
into finite state machines and will eventually be building
a parser generator tool that will use
regular expressions for the scanner generator and
also on the right side of productions.
I plan to provide support for at least three additional
unary operators to the standard three (?,*, and +)
(plus new binary operators but that's a topic for another day).
For a regular expression R they are:
R! :does not accept the empty string but otherwise
accepts every expression that R does. Very useful.
R~ :accepts exactly the set of strings that R does not accept.
note that R = R~~.
R% : equivalent to the string (R~)R
I have put these operators after the expression but in fact I prefer
to have them in front
1) I prefer to have unary operators in front of their expressions
as in "-5" rather than "5-".
Yes, I know, what about 5! (5 factorial).
2) Parsing is easier and faster if the unary operator precedes
But the standard unary operator always follow the expression
in every example I have seen (OK, I have seen one exception).
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.
a) frustrates me because I am then extending (in my mind) a bad
b) worries me because users may not like it.
c) is just weird.
d) is too complex and I don't think the user wants this feature.
Before I decide I would like to hear opinions on the matter.
Suggestions as to further operators to support welcome. Suggestions
as to what are the best symbols to use for the new operators welcome.
Return to the
Search the comp.compilers archives again.