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) |
[5 later articles] |
From: | Ralph Boland <rpboland@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 29 Mar 2009 23:49:30 -0700 (PDT) |
Organization: | Compilers Central |
Keywords: | lex, question |
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
because:
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
the expression.
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
decision.
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.
Ralph Boland
Return to the
comp.compilers page.
Search the
comp.compilers archives again.