Bruno Le Floch skrev 2011-10-10 17.07:
> Hello all,
> We just added on CTAN two related modules:
Did you by any chance mean SVN rather than CTAN? (Or maybe there is a delay
in changes becoming visible.)
> The l3regex module allows for testing if a string matches a given
> regular expression, counting matches, extracting submatches, splitting
> at occurrences of a regular expression,
Sometimes one goes the other way, and returns all matches of a string. I
wouldn't go so far as saying that this is more useful than splitting at
things that match, however.
>and doing replacement (see
> documentation for function names).
> Speed requirements forbid a back-tracking approach, hence
> back-references cannot be supported. Only "truly regular" features are
Having browsed the code now, I see that you execute the automaton in general
NFA form. Have you considered executing it in epsilon-free NFA form instead?
Getting rid of epsilons does not increase the number of states (it can even
reduce the number of reachable states), but I'm not sure how it would
interact with match path priority...
> - Newlines. Currently, "." matches every character; in perl and PCRE
> it should not match new lines. As you know, the situation with new
> lines in TeX is a little bit odd, since they are converted to the
> \endlinechar upon reading, and normally not tokenized, simply giving
> rise to a space or a \par. Should we still decide that "." does not
> match the CR nor LF characters? Or should it simply no match the
The way I'm used to regexps, you can control using "metasyntax" whether .
matches newline or not, and likewise how ^ behaves with respect to
beginning-of-line, so I wouldn't find it wrong if ^ and \A are synonyms.
> - Same question for caseless matching, and for look-ahead/look-behind
Can you even do assertions without exploding the number of states? (Whenever
I've thought about it, I tend to end up with the conclusion that one cannot,
but I might be missing something.)