Re: Regular Expressions Proposal

Andy Heninger <[email protected]>
Newsgroups gmane.comp.lib.icu.general
Message-ID <[email protected]>
Looking more closely at the proposed regular expression extension

> 3.  Add new API
>     UBool  RegexMatcher::touchedEnd();
> 
>     Return true if the most recent attempted match or match touched the
>     end of the input string.  
>      [...]
>     The intent of this function is to allow a determination of
>     potential matches to be made while input text is incrementally
>     received.

This is turning out to have an awkward interaction with some of the 
speed optimizations.  The pattern compiler computes a minimum possible 
match length, based on items in the expression that can not be skipped. 
    If the minimum match length < the string length, the match engine is 
not even started, and there is no information about whether the start of 
the pattern matched whatever string there was.

The same thing happens with find(), which must check for possible 
matches at each potential matching point.  We've got many optimizations 
to weed out excess possible matching spots, one being too little string 
left for a match.

Within the match engine itself, the same thing happens again, but at a 
lower level.  Whenever the pattern contains a literal string that cannot 
possibly match because of too little input left, no partial match test 
is done.

I'm very hesitant to neuter these optimizations.  Performance is 
important, and it was a lot of work to bring ICU regexps up to the point 
that they were competitive with other regexp packages.

So what to do?  Some possibilities are

1.   Ignore the problem, say that the results from touchedEnd()
      are just a hint, and may be wrong.

2.   Have a mode of the RegexMatcher object for enabling touchedEnd().
      This mode would disable the optimizations.

3.   Accept the performance hit.

4.   Withdraw the proposal for touchedEnd(), at least for now.

5.   Make support for touchEnd() be a property of the Pattern, a flag
      to be set when the pattern is compiled.   This would probably
      have the least performance impact, but seems like it would be
      awkward for users.  I don't like it.

Opinions?  I lean toward either 2 or 4.

   -- Andy Heninger
      [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.