Qt-interest Archive, March 2007
QRegExp enhancement
Message 1 in thread
I'm not exactly sure if this is an appropriate forum for feeding the troll
feature requests, but I'll present my ideas anyway.
Motivation:
I was writing a widget to accept input of geographical coordinates, that is
a QLineEdit with a QRegExpValidator that would validate for several forms
of a geographical coordinate (mgrs, utm, 3 types of DMS, 2 types of decimal
degrees). So I began with composing a regular expression for each of the
different input forms. But now I am required to unionize those strings into
a single long and cryptic string because QRegExpValidator can only accept a
single QRegExp. What an ugly situation.
Proposed Enhancement:
I recall from my knowledge of CS that Regular Expressions closed under the
union, intersection, concatenation, and complement operations. I therefore
think that QRegExp should have methods for each of the following.
QRegExp union = QRegExp("pat1") | QRegExp("pat2");
QRegExp intersect = QRegExp("pat1") & QRegExp("pat2);
QRegExp concat = QRegExp("pat1") + QRegExp("pat2");
QRegExp complement = !QRegExp("pat1");
I'm not particular on wether the | & + and ! operators are overloaded, or
new methods are added that go by the names union, intersection, concat,
complement. I'm just really looking for the functionality of building a
QRegExp from existing smaller QRegExp's.
I really think this would be a nice addition, and the additional
functionality wouldn't suprise anyone that's gone through a rigorous class
on FSM's and Regular Languages.
--
[ signature omitted ]
Message 2 in thread
This would be a wonderful addition... I find that 99% of the coded
regex's I create, I wind up having to put a Q_ASSERT( regEx.isValid() )
right after just so I can test I typed it correct.
However, I have a slightly different approach to propose.
A QRegExBuilder class. That had more then just concat/union/intersect
etc... But also had "zeroOrMore", "oneOrMore", "anyCharIn" etc etc..
While this might seem overly verbose, the goal, would be that you could
add RegEx feature, just like you would to a QString... In the end, you
could do a "builder.toRegEx()" which would construct the proper regEx
for use.
It would sure get rid many of the regex questions that come up on the
list.
Scott
> -----Original Message-----
> From: Eric the Fruitbat [mailto:the.theorist@xxxxxxxxx]
> Sent: Thursday, March 29, 2007 2:34 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: QRegExp enhancement
>
>
> I'm not exactly sure if this is an appropriate forum for feeding the
troll
> feature requests, but I'll present my ideas anyway.
>
> Motivation:
> I was writing a widget to accept input of geographical coordinates,
that
> is
> a QLineEdit with a QRegExpValidator that would validate for several
forms
> of a geographical coordinate (mgrs, utm, 3 types of DMS, 2 types of
> decimal
> degrees). So I began with composing a regular expression for each of
the
> different input forms. But now I am required to unionize those strings
> into
> a single long and cryptic string because QRegExpValidator can only
accept
> a
> single QRegExp. What an ugly situation.
>
> Proposed Enhancement:
> I recall from my knowledge of CS that Regular Expressions closed under
the
> union, intersection, concatenation, and complement operations. I
therefore
> think that QRegExp should have methods for each of the following.
>
> QRegExp union = QRegExp("pat1") | QRegExp("pat2");
> QRegExp intersect = QRegExp("pat1") & QRegExp("pat2);
> QRegExp concat = QRegExp("pat1") + QRegExp("pat2");
> QRegExp complement = !QRegExp("pat1");
>
> I'm not particular on wether the | & + and ! operators are overloaded,
or
> new methods are added that go by the names union, intersection,
concat,
> complement. I'm just really looking for the functionality of building
a
> QRegExp from existing smaller QRegExp's.
>
> I really think this would be a nice addition, and the additional
> functionality wouldn't suprise anyone that's gone through a rigorous
class
> on FSM's and Regular Languages.
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 3 in thread
What you've described sounds closer to a full parser to me. Which would also
be a nice addition to the Troll framework, though another discussion
entirely.
I was thinking more along the lines of minimal changes to the existing
system. Although, reflecting on it for the past day, I'm pretty sure the
reason it doesn't support what I proposed is that Regular Expressions are
by no means regular; and what would concatenation do for features like
grouping, back-substitution, and the look-ahead/behind stuff? The
implementation would be difficult.
All these extended features make RegExp's non-regular (in the mathematical
sense) and so we lose closure over the properties I described in my
original proposal. For validation purposes I don't mind the loss of
grouping, but for crude parsing/splitting of stuff it's essential. Maybe a
full parsing framework is unavoidable.
I'll look-up and refresh my memory more about push-down automatons, since
the extended RegExp's seem to require a memory of sorts.
> Scott Aron Bloom wrote:
> This would be a wonderful addition... I find that 99% of the coded
> regex's I create, I wind up having to put a Q_ASSERT( regEx.isValid() )
> right after just so I can test I typed it correct.
>
> However, I have a slightly different approach to propose.
>
> A QRegExBuilder class. That had more then just concat/union/intersect
> etc... But also had "zeroOrMore", "oneOrMore", "anyCharIn" etc etc..
>
> While this might seem overly verbose, the goal, would be that you could
> add RegEx feature, just like you would to a QString... In the end, you
> could do a "builder.toRegEx()" which would construct the proper regEx
> for use.
>
> It would sure get rid many of the regex questions that come up on the
> list.
>
> Scott
--
[ signature omitted ]
Message 4 in thread
On 30.03.07 08:43:15, Eric the Fruitbat wrote:
>
> What you've described sounds closer to a full parser to me. Which would also
> be a nice addition to the Troll framework, though another discussion
> entirely.
Have you seen this:
http://labs.trolltech.com/page/Projects/Compilers/QLALR
AFAIK its used for the QtScript parser.
Andreas
--
[ signature omitted ]
Message 5 in thread
> Andreas Pakulat wrote:
>
> Have you seen this:
>
> http://labs.trolltech.com/page/Projects/Compilers/QLALR
>
> AFAIK its used for the QtScript parser.
>
How remarkably serendipitous. That would be extremely useful for other stuff
I do that requires the automated changing/generation of different types of
log/configure files.
--
[ signature omitted ]
